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In this Issue 




The 1990s may be remembered as the decade when multimedia capability 
became commonplace in computer technology, communications, and enter- 
tainment. The exact meaning of multimedia depends on who's using the word. 
On HP engineering workstations (HP 9000 Series 700 and 800 computers), one 
meaning of multimedia is HP MPower, a collection of multimedia hardware and 
software tools and applications that allow users to create, manipulate, and 
share textual information and nontextual information such as audio, image, 
graphics, and video data over a network. 

As described in the article on page 10, on an HP MPower-equipped workstation 
the following services are available to the user: faxing, online documentation, 
scanning, image viewing, audio recording and playback, video in a window, window capture, whiteboard 
collaboration, real-time application sharing, and color graphics and PostScript™ printing. The development 
of HP MPower has been an evolutionary process, with new capabilities being developed as user needs 
changed and new technologies became available, and the product continues to evolve. The article on 
page 6 tells the story of this evolution and goes on to describe two very recently released HP MPower 
capabilities: digital video, or full-motion video with synchronized audio, and telephone functionality with 
a new HP MPower telephony component, HP TeleShare. These last two media types were added to HP 
MPower too late for articles on them to be prepared in time for this issue. We hope to include articles on 
their design in a future issue. 

HP MPower, its various components, and its client/server architecture are introduced in the article on 
page 10. HP MPower's graphical user interface is the HP Visual User Environment, HP VUE. It's the subject 
of the article on page 20. The application sharing component of HP MPower is HP SharedX (page 23), a 
communication tool that extends the industry-standard X Window System so that two or more users at 
different workstations can share and interact with the same X-protocol-based applications almost as if 
they were at the same workstation. Existing X applications don't have to be changed to be shared with 
HP SharedX. Implementing this new application sharing technology in a heterogeneous computing envi- 
ronment, the designers discovered, poses many difficult design challenges, some of which don't have 
perfect solutions. A component of HP SharedX called Whiteboard (page 28) allows users to share a 
snapshot of a portion of a display and to annotate that snapshot. 

Image files contain computer graphics and digital records of physical objects such as photographs, 
pages from books, and faxes. The HP Image Library (see page 37) contains image manipulation tools, 
compression and decompression functions, picture quality adjustment functions, and support for indus- 
try standards. Its functionality is used by several HP MPower components. For environments in which 
users have a multitude of printers to choose from, HP SharedPrint (page 44) provides a simple graphical 
interface that enables users to select a target printer and a set of options without many of the typical 
problems. The HP MPower fax utility (page 53) provides automatic dialing, transmission, and delivery of 
facsimile documents from a workstation. 

HP MPower provides the hardware and software for recording and playing audio files over a network, 
incorporating audio in email, adding audio annotations to system files, and recording and playback using 
external devices such as tape recorders, CD players, and VCRs. HP MPower's audio functionality, appli- 
cation development tools, and hardware and software audio architecture are described in the article on 
page 62. Video technology in HP MPower is provided by a hardware/software component called HP 
VideoLive (page 68). It provides full-motion video in a movable, scalable window and works with existing 
HP graphics subsystems without degrading system or graphics performance. 
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HP MPower also provides a multimedia email, or electronic mail, facility (see page 71). The well- 
established processes of creating, sending, receiving, printing, and replying to email messages are 
maintained and applied to messages containing multimedia objects such as image and audio files. 

Nearly 2000 online help topics are shipped with HP MPower. The HP online help system used by HP 
MPower and other HP applications is described in the article on page 79. On page 90, one of the designers 
of the HP help system advises application developers on the issues they may encounter in providing 
online help for their applications. 

R.P. Dolan 
Editor 



Cover 

A workstation screen showing the HP MPower media panel and the HP MPower applications Image- 
View, which provides capabilities for manipulating and viewing different types of images, MailEditor for 
creating multimedia email, and Whiteboard, which enables two or more users to collaborate on the 
same image from different workstations. 



What's Ahead 

Coming next are design articles on the HP 9000 Model T500 corporate business server and the SoftBench 
Message Connector. There will also be technical articles on the use of fuzzy logic to assign printed circuit 
assemblies to production machines and on cleanroom software. 
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Development of a Multimedia Product 
for HP Workstations 

Providing multimedia capability on HP's workstations was an evolutionary 
process that was paced according to customer needs and the availability 
of quality multimedia hardware and software technology and low-cost 
workstations. 

by Gary P. Rose, Jeffery T. Oesterle, Joseph E. Kasper, and Robert J. Hammond 



Multimedia technology was a burgeoning market when HP's 
Workstation Group first looked at it in 1990. A lot. of promise 
and exaggerated claims surrounded multimedia technology 
at the time. The question was how MP workstations could 
create a competitive advantage with the technology. The an- 
swer to this question resulted in HP MPower, a collection of 
multimedia tools and applications which are described in the 
articles in this issue beginning with an overview on page 10, 

This paper will describe the development history of HP 
MPower and how it turned HP workstations from simply 
computational tools into media-rich information access and 
communication channels for business and industrial users. 

The Start 

Looking at the marketplace back in 1990 there were a num- 
ber of application areas in which multimedia technology was 
being applied, Personal computers were being upgraded 
with CD-ROMs and sound cards, and typical multimedia 
application areas included presentations, computer-based 
training, and games. Workstations have difficulty competing 
with low-priced PCs for these markets. Since integrated 
networking capability was an advantage that workstations 
had over PCs at that time, we looked for markets that had 
distributed media requirements. We focused on two applica- 
tion segments: multimedia information management and 
real-time communication. The information-management 
market included document image management, work flow, 
and corporate training. Hie real-time communication mar- 
ket included workspace sharing, multimedia email, confer- 
ence management, networked fax, telephone integration, 
and video teleconferencing. 

We visited our customers to leant about challenges facing 
their businesses so that we could determine where we could 
offer solutions. A common theme we heard was that these 
companies needed to be more productive without signifi- 
cant increases in personnel. They were global companies 
that needed to align their teams on common objectives, and 
get t hem working together. Increasingly, they relied on dis- 
tributed teams, alliances, and experts outside their com- 
pany. The need for communication among these teams was 
critical to their success. 

Communication between humans is more effective when it 
is natural. Media types such as recorded voice, pictures, and 
movies can add information to the communication that goes 



far beyond what traditional text can achieve. Facial expres- 
sions, body language, and tone of voice add cues to the 
meaning of the message. These cues help convey trust and 
understanding of what is being communicated. Multimedia 
computers can go far beyond traditional email in helping to 
facilitate communication, resulting in faster exchange and 
absorption of ideas. However, computer-assisted communi- 
cation tools have to be easy to use and a natural part of the 
environment for them to be adopted by large numbers of 
people. 

Although we wished that everyone owned an HP workstation, 
our customers did not have homogeneous HP environments. 
If the technologies we provided did not work with their exist- 
ing equipment, then it would be difficult for them to deploy 
our products within their enterprises. Additionally, the im- 
portance of standards is very high in communication since 
they ensure that no one is excluded from a conversation 
because of the type or equipment they have. 

We had three clear challenges for bringing multimedia to 
corporate offices. First, we had to deal with the limited net- 
working capabilities of most existing environments. Second, 
the technology needed to be pervasive for people to use it. 
Finally, the technology needed to be very low-cost to be 
affordable for deployment within the enterprise. 

End users were pulling the application developers into the 
multimedia arena. Thus, we needed to create desktop tools 
so users could immediately take advantage of multiple types 
of media without waiting for the applications to be devel- 
oped. These tools also had to include examples of how to 
use the programming interfaces to the multimedia services 
so that application developers could immediately provide 
multimedia capability in their applications. 

We wanted to leverage as much as possible the expertise 
within HP so we contacted numerous HP organizations. A 
PC-based collaborative multimedia project from IIP Labora- 
tories in Pinewood and Bristol, England was one of the 
pieces of research that helped guide us. Engineers in Bristol 
demonstrated that for distributed work groups trying to 
solve a range of tasks, a shared drawing space that allows 
multiple users to annotate a picture was very effective in 
improving productivity. Audio communication was consid- 
ered the second most productive tool among these work 
groups. Surprisingly, seeing a video of the person they were 
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working with didn't improve productivity measurably. How- 
ever, it is interesting that they perceived they were more 
productive when using video to show the object being 
discussed. 

Our customer feedback was that although they all wanted to 
be able to do video conferencing from their desks, they did 
not have the network infrastructure in place Also, when 
asked which media they would incorporate in their training 
and documentation, the answers were overwhelmingly in 
favor of images and audio. We felt that it was important to 
stage technologies for customer acceptance, and build up 
the capabilities over time. We decided to defer distributed 
digital video support untiJ customers became comfortable 
with digital media over networks and implementations were 
cost-effective. 

To keep the incremental costs for multimedia down we tried 
to implement as much as possible in software running on a 
PA-RISC CPU. This also allowed us to adapt our systems 
easily to new algorithms and standards, to provide access to 
our installed base, and to take advantage of new processor 
improvements. 

1991— The Base Platform 

Our customer feedback implied that the first technologies to 
be integrated should be image and audio. We asked custom- 
ers about their imaging needs and found that while comput- 
ers could display images, users typically had to run them 
through several conversion steps before their display pro- 
grain could put the image on the screen. Among graphics 
products there was a wide range of image formats and frame 
buffer pixel depths. This made image display inconsistent 
from machine to machine. Another problem was t hat the 
screen would turn funny colors when more than one image 
was displayed at a time because of the lack of color map 
sharing. 

We addressed these problems with an image library and 
tried to make images as easy to use as text and graphics. We 
integrated image and audio libraries into the HP-UX* operat- 
ing system so that applications would have an installed base 
for their functionality. There were no standards available for 
programming interfaces, so we modeled the interfaces to feel 
like X windows, which is a paradigm familiar to our applica- 
tion developers. Rather than creating HP file formats, com- 
mon formats from the PC and Apple Macintosh worlds were 
used and conversion services were provided to import and 
export data from these plat forms. We used algorit hm exper- 
tise from HP I^aboratories and the CPU power of our systems 
to include compression and decompression of images using 
the JPEG (Joint Photographic Expert Group) standard, 
which allows images to be useful on low-end machines with 
small disks. The image library was designed as an extensible 
pipeline architecture that would allow applications to add 
new file types or special operations. 

Our approach to audio support was to integrate audio on the 
motherboard of our workstations. Instead of taking the tradi- 
tional approach of providing a DSP (digital signal processor) 
for moving the audio to the CODEC (coder/decoder), we use 
the main processor. This not only saves the cost of the DSP 
but also the dedicated memory for the DSP and other support 
logic. The PA-RISC processor is much faster than commercial 



DSPs, and it allows more complex functions to be applied to 
media streams. 

We felt it was important to develop small applications such 
as an audio editor that would provide end user tools so 
there would be market demand for the technologies. We also 
gave away the source code for these small applications so 
that developers would have working examples to start with 
when they dev eloped their own applications. 

The audio and image library were packaged with our X 
window sharing product HP SharedX. making up our first 
multimedia offering. The audio library, the image library, 
and HP SharedX are described on pages 62, 37. and 23 
respectively. 

1992— Media I/O 

In 1992 we decided to make our existing teclinologies more 
useful and postponed digital video. We felt we could bring 
our customers more value by leveraging the strengths HP 
had in computer products and integrating those products 
with the base tools. We ported the HP ScanJet lie from 
Microsoft* Windows to the X Window System to provide a 
way to get images into the workstation. We created a product 
called HP SharedPrint to allow a multitude of image formats 
to be printed on the wide range of PCL and PostScript IM 
pri nters available. We added fax technology so that users 
could have another way to communicate with images. This 
would also allow communication with people outside their 
normal networking environment. We collaborated with third- 
party vendors to provide hardware for video in a window 
and to allow users to capture digitized frames from the 
video. HP SharedPrint, HP MPower fax, and our first video 
offering are described on pages 44, 53, and 68 respectively. 

We upgraded the audio that is built onto the CPU board to 
CD quality to anticipate low-cost speech recognition, text-to- 
speech capability, and computer-based training. The HP-UX 
elm mailer was integrated with the new media data types to 
handle compound document mail messages using the inter- 
net standard MIME (Multipurpose Internet Mail Exten- 
sions). To improve the usability of the system we did exten- 
sive up-front task analysis. We determined how the tools 
would be used to accomplish different tasks and worked to 
eliminate the number of steps users needed to succeed at 
those tasks. We made the user interfaces appear more con- 
sistent among the different tools. We used HP SharedX to 
replicate our graphical user interfaces and solicited feed- 
back from the different HP organizations developing compo- 
nents for HP MPower and HP VUE (Visual User Environ- 
ment) 2.0 customers. The HP VUE team worked closely with 
us to integrate the media and collaborative tools into the 
control panel of the HP VUE 3.0 control panel. We delivered 
this collaborative user environment to the market under the 
name IIP MPower 1.0. 

HP VUE 3.0 and the new elm editor are described on pages 
20 and 71 respectively. 

1993— Ready for Video 

In 1993 we improved HP MPower in three dimensions by 
adding digital video, integrating telephony, and dramatically 
improving the flexibility for configuring the client/server 
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environment so that fax and prim servers ran reside on 
different machines. These features became HP MPower 2.0. 



MPEG-1 maintains a high-o,ualit.y image (comparable to VHS 
tape) while supporting compression ratios up to 200:1. 



Digital Video in HP MPower 

Recent advances in computer-processing speed and video- 
compression techniques have made it possible to combine 
full-motion video and synchronized audio into a form of 
computer data. This data, known as digital video, can be 
delivered over standard computer and telecommunication 
networks and can be integrated into multimedia applications 
such as computer-based training programs. 

In the computer-based training market, there is typically a 
small number of authors and a large number of people who 
use this form of training. ( )ur goal was to deliver cost- 
effective digital video playback for desktop computer-based 
training. We worked with HP Laboratories and the HP 9000 
Model 712 team to integrate the video playback algorithms 
tightly into the PA-RISC 7100LC chip. The graphics loam 
provided new blithering (dithering and visual blending) algo- 
riihms and media-oriented frame buffer access modes that 
greatly assist in the rendering performance, giving the ap- 
pearance of a 24-bit system with the cost of an 8-bit system. 

Standards-Based File Format. HP's digital video implementa- 
tion supports the MPEG-1 (Moving Pictures Expert Group) 
file format. MPEG-1 is an internationally recognized stan- 
dard for compressing synchronized audio and video data. 



Key Benefits. HP MPower users can play MPEG-1 movies on 
any HP 9000 Series 700 workstation without additional hard- 
ware. The new HP 0000 Model 712 workstation provides 
exceptional price/performance value for playing video be- 
cause of instruction set enhancements to the Model 712's 
PA-RISC chip and enhancements to the graphics subsystem. 

Since MPEG-1 movies are a form of digital data they can be 
transferred to other users via email or standard HP-UX 
commands such as ftp or uucp. 

Digital Video Components. IIP MPower 2.0 has two digital video 
soft ware components: the video player and the video con- 
verter. The video player software plays MPEG-1 movie files 
with or without audio (see Fig. 1). The user can adjust the 
size of the window and adjust the audio and video qualities. 
Any frame in the video can be examined, and play forward 
or reverse capabilities are also available. Video frames can 
be captured and saved as TIFF, JF1F, Xbm, or Xwd images. 
Images can also be printed directly from the application. 

The video conversion utility converts JPEG movie files to 
MPEG-1 format. JPEG (Joint Photographic Expert Group) is 
an internationally recognized standard that deals with the 
compression of still images. 



Video Player — conan:/users/video/hp1.mpg 
File Options Help 



1 

r 
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<ll 4\ !► !!► 6065 



Play Pause 


Stop Volume.., 





Fig. 1. The digital video player 
playing an MPEG-1 movie file. 
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MPEG-1 movies can be obtained by capturing video data 
from an external source such as a video camera and storing 
it in JPEG movie files. ' The JPEG files can then be con- 
verted to MPEG-1 format with the video conversion utility. 
Alternatively, customers can use a service bureau to convert 
their video material to MPEG-1 format. 

Telephony 

The integration of telephone functionality on a workstation 
provides users with a powerful communication tool that 
enhances the use of both the telephone and the computer. 
The telephone becomes easier to use because the computer 
can take care of the details of telephone use such as special 
function buttons, volume control, finding and dialing phone 
numbers, and tracking telephone use. The computer be- 
comes a more effective communication and collaboration 
tool. Also, with telephone access, users can send faxes from 
their desktop, share their computer audio over the tele- 
phone, and get caller information from a database based on 
the caller identifier (e.g., telephone number). 

HP's telephony product, or HP TeleShare, provides a two- 
line telephony card for HP's 9000 Model 712 workstation. 
The HP TeleShare card is an optional daughtercard, with 
two complete analogtt telephone line interfaces. Each tele- 
phone line has a digital signal processor to provide data and 
fax modem support and to handle audio mixing for voice 
mode use. Having iwo telephone lines provides the capabil- 
ity to place a telephone call using one line while setting up a 
data or fax connection on the other line. 

HP TeleShare also includes a telephone application that pro- 
vides users with access to various telephone functions from 
their workstations. For switching the mode of each telephone 
lino between data modem, fax modem, and voice there is a 
small control application thai controls the mode of each HP 
TeleShare line and reflects any changes in mode to the user. 
Fax functionality is provided through a single-user configura- 
tion of the HP MPower fax facility, while data modem func- 
tionality can be accessed through the user's favorite data 
communications package such as kermit or cu, provided they 
are configured to use the HP TeleShare card as a modem. 

HP TeleShare has direct access to the HP MPower audio 
subsystem on the workstation, which is what makes it pos- 
sible for a workstation with the audio headset to be used as 
a full-function telephone. This also makes it possible to 
share computer-generated audio over the telephone line and 
to record telephone conversations into computer audio Tiles 
for later reference. Because telephone audio is low-quality, 
IIP TeleShare provides services to deal with quality levels. 
The audio server automatically resamples the computer 

t A third-party video card must be used 10 capture JPEG movies 

1 1 Analog telephone line teters to thB traditional. Plain-Dld-Telephone- System IPOTSI telephone 
lines, as opposed to ISDN Imlegraled-services digital network) or ISDN-like proprietary 
digital telephone systems. 



audio so that the user is not c onstrained by this restriction. 
This makes it possible to play CD-quality samples over the 
telephone line or to record from the telephone line into a 
CD-quality sample file. 

Applications. Two OSF/Motif applications are provided with 
HP TeleShare. The first is called teleshare, which provides a 
graphical user interface to the telephone functions provided 
by the product. These functions include a telephone keypad, 
volume and hook controls, forwarding buttons, program- 
mable speed dial keys, and a display area for mcoming call- 
er-identifier information. 

The second application, called telctrl. provides control and 
status information on the media modes (fax, data, voice) for 
the HP TeleShare telephone lines (described below). There 
is also a helpful graphical setup and configuration program 
to help the system adrriinistrator configure the HP TeleShare 
product properly. 

Fax and Data Modem Lines. HP TeleShare can function as a 
fax or data modem in addition to serving as a full-function 
telephone. The telctrl application allows control of the cur- 
rent mode of each of the HP TeleShare telephone lines, as 
well as reflecting any changes in the mode. The mode can 
also be changed automatically when a modem application 
opens a connection to the port supplied for interfacing to 
HP TeleShare 's modem functionality. Only one line at a time 
can be used as a modem, but the other telephone line would 
be available for voice mode use. 

A single-user configuration of the HP MPower fax product 
is shipped with HP TeleShare to provide support for fax 
functionality. 

Conclusion 

Enhancements or additions to the HP MPower product will 
be guided by our ability to leverage HP and external multi- 
media tools and technologies and integrate them into the 
product to reduce cost and to take advantage of HP's distrib- 
uted computing and object-oriented design expertise. We 
will continue to listen to our customers' needs and provide 
frameworks that will allow lighter integration of the parts to 
improve usability. Our internal use of the collaborative tools 
for our own communicat ions with remote experts and teams 
both inside and outside of HP will provide us with additional 
insight into communication needs for the future. 

HP-UX is based on and is compatible with UNIX System laboralones' UNIX* operating system 
It also complies with X/Open s" XPG3. POSIX 1 003 1 and SVID2 interlace specifications 

UNIX is a icgisteied trademarti of UNIX System laboratories Inc in IheUSA anil oilier countries 

X/Open is a trademark o( X/Open Company limned in ihe UK and other countries 

Microsoft is a U.S. registered trademark of Microsoft Corporation 

Windows is a U S trademark of Microsoft Corporation 

PostScript is a trademark ol Adobe Systems Incorporated which may be registered in certain 
jurisdictions. 

OSF/Motif is a trademark of Ihe Open Software foundation in Ihe U S and other countries 
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HP MPower: A Collaborative 
Multimedia Environment 



Multimedia capability on a workstation enables users to interact with 
their applications and communicate with others in a variety of formats 
(textual and nontextual). HP MPower provides an environment in which 
users have easy access to the multimedia facilities at their workstations 
and application developers can easily add new multimedia tools. 

by William R. Voder 



Imagine being able to have a project team meeting in which 
the participants are widely dispersed but are able to collabo- 
rate from their desktop workstat ions as if they were all in 
the same room. To carry out such an electronic meeting, the 
participating workstations must provide the facilities that 
allow users to create, manipulate, and share textual and 
nontextual information such as audio, image, and video data 
over a net work. 

HP MPower provides workstation conferencing and the 
collaborative sharing capabilities mentioned above. Unlike 
video teleconferencing, which requires a significant hard- 
ware ami networking investment, HP MPower is a low-cost 
software product that works with today's workstations and 
networks. HP MPower offers a full range of multimedia types 
such as audio, image, graphics, video, and lext (Fig. 1 ), with 
five ways of sharing information: print, mail, fax, whiteboard, 



and real-time application sharing. HP MPower offers access 
to this set of multimedia tools through the HP VUE 3.0 
graphical user interface. 

IIP MPower is currently supported on lite HP 9000 Series 
700 and 800 workstations and HP X stations. 

The Media-Equipped Knowledge Worker 

A typical knowledge worker uses a workstation to process 
information in the form of documents, spreadsheets, graph- 
ics presentations, and so on. In addition to these items, the 
media-equipped knowledge worker has access lo sound 
clips, video frames, scanned images, faxes, and other media 
objects. Whether among a local team or among colleagues 
who are scattered geographically, the media-equipped knowl- 
edge worker benefits by sharing high-fidelity information at 
a high bandwidth. 




Fig. 1. A typical HP MPower dis- 
play showing windows open for 
whiteboard, images, and video. 
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Fig. 2. Multimedia mail ('omixising. 

Workstations and PCs capable of providing multimedia 
access have until recently existed as islands of technology, 
only good for standalone applications. A developer logs into 
such a workstation and creates, say, a training module that 
end users can access only at the isolated workstation. By 
combining the power of media technology with networked 
systems running the HP-UX* operating system, HP MPower 
enables users to collaborate effectively via a workstation 
medium. 

For example, suppose Margaret wants to send her col- 
leagues a document consisting of text, a scanned image of a 
competitor "s magazine ad, and a voice clip commenting on 
the article. She presses the mail button on the IIP VUE front 
panel shown in Fig. 1 to compose the mail message shown 
in Fig. 2, presses the scanner button on her IIP MPower 
media panel lo scan in the ad, and (hen presses the audio 
button to record her comments. Finally, she drags and drops 
the scanned image and voice clip into her mail message and 
sends it on its way. 

As another example of using this media-equipped work- 
station, consider Jeffrey who wants to work on a CAD draw- 
ing with his colleagues in Colorado and Washington. From 
the HP VUE file manager, he drops the drawing into a white- 
board window on his workstation, calls his colleagues on 
the telephone, and uses the whiteboard window to interact, 
and collaborate with his colleagues. The whiteboard and I he 
soil ware for sharing windows are discussed in the article on 
page 23. 

The IIP MPower System 

On a fully-equipped HP MPower-enabled workstation the 

following services are available lo the user 

Faxing 

Online I tociimentation 

Scanning 

Image Viewing 

Audio Recording and Playback 
Video-in-a- Window 
Window Capture 
Whiteboard Collaboration 
Application Sharing 

Color ( iraphics and PostScript™ Priming. 

Many of the services listed above are accessible from the IIP 
MPower media panel shown in Fig. % Some Of the Other IIP 
MPower features accessible from the fronl panel include: 




Send and Receive Faxes 



Scan Monochrome and Color Images 



View Xwd. Xbrn. TIFF. GIF. Storbasc, 
and JPEG Images 



Play. Record, and Edit Audio 



View Video in a Window from a Variety of 
Video Sources and Capiure Video Frames 



Capture Window Contents 



Import, Share, and Annotate Images 



Share Application Windows 



Fig. 3. HP MPower media panel 

' Audio control for adjusting global audio output devices 
i I Ielp control for accessing system-wide online documentation 
i Prinl control for printing text and graphics, managing print 
requests, and administering printers 
1 Mail control for reading and composing plain text ;uid media- 
embedded mail messages. 

Hardware Components. The basic HP MPower workstation 
consists of a high-resolution display, a keyboard, and a 
mouse. For a fully-equipped IIP MPower multimedia 
workstation Ihe other hardware components include: 

1 Built-in 8-bit or 16-bit audio with speaker or plug-in headset 

i External scanner with SCSI interface 
External fax modem (or modems) with serial interface 
KISA-based video card 
A variety of serial and parallel printers. 

Software Components. HP MPower software consists of a 
number of lightly integrated media tools coupled lo the IIP 
VUE :1.0 user environment with interprocess communication 
mechanisms for distributed processing. HP VUE 3.0 and IIP 
MPower are peers in the soft ware hierarchy (see Fig. 4). 
When the user selects an IIP MPower media object (e.g., 
audio file) from the HP VUE 3.0 display, HP VUE hands con- 
trol over to IIP MPower to take the appropriate action on 
the object. 
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OSF/Moiif Widgets 



X Window System 




Operating System and Network Software 



Hardware Platform 



Fig. 4. The software hierarchical relationship between HP VUE 3.0 
and HP MPower. HP VUE 3.0 provides user interface anil desktop 
services for the look and style of HP MI'ower media objects, and 
HP MI'ower provides the actions assoc iated with a particular media 
object. 

A typical media tool consists of art OSF/Mot if-based client 
application, its run-time libraries, a backend server process, 
and the appropriate device drivers (see Fig. 5). At the lowest 
level, the device drivers control the hardware. For example, 
the VideoLive card uses an X-server exteasion to access the 
frame buffer. This X-server extension enables direct hard- 
ware access to the frame buffer, so that the VideoLive client 
can manipulate 24-bit G40-by-480-pixel images within the 
context of an 8-bit root window. Media server components 
are described in more detail later in I his arucle. and the 
VideoLive card is described in the article on page 68. 



HP MPower Media 
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/ Server 
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Fig. 5. The architecture for a distributed multimedia application. 



Important MP MPower run-time libraries include the image 
and audio libraries, which are described in the articles on 
pages 37 and 02, respectively. 

The User Interface 

From a user's point of view, the IIP MPower workstation 
consists of an integrated set of tools and their associated 
media objects. I IP MPower provides facilities that enable 
the user to: 

• Create media objects like a video frame sequence 

1 Browse objects such as an incoming fax 

1 Edil objects such as an audio track 

1 Share objects such as a workstation window. 

The appearance and behavior of IIP MPower are derived 
from the OSF/Motif style guide and from the HP VUE 
desktop. For example: 
1 Users can double-click to invoke actions, as in playing an 
audio file 

■ Users can drag and drop media objects on HP MPower 
tools, as in dragging and dropping an image file on the fax 
composer. 

HP MPower tools are mouse-driven with pushbuttons, 
pull-down menus, and dialog boxes. 

The HP VUE 3.0 interface is described on page 20. 
Objects and Actions 

The file-typing mechanism used by HP VUE is extended to 
media objects. For example, PostScript files are denoted by 
a .ps suffix appended to the base file name (e.g., Article.ps). 
The HP MPower media tools such as the audio editor ensure 
that files are created with the appropriate suffix. 

Each media object has certain allowable actions or methods. 
For example, for audio files appropriate actions include Play, 
Edit, and Mail, and for image files appropriate actions include 
View, Print, Mail, and Fax. Table I lists the objects and actions 
supported in HP MPower 1.0. These HP MPower actions 
extend the predefined IIP VUE 3.0 objects and actions. 

Online Documentation 

Extensive online documentation is provided with I he IIP 
MPower system. Built on the HP VUE 3.0 help system, HP 
MPower online documentation includes component level 
documentation (e.g., help on the fax composer) and system 
level documentation (e.g., the "Welcome to IIP MPower" 
chapter). 

Top level indexes provide users with easy access to all the 
help volumes on their system. The many hyperlinkst among 
topics allow users to browse hundreds of pages of task- 
oriented and reference material, which may or may not be 
related to the task they are performing. Another type of help 
called item help enables users to find answers as they use the 
media tools in the context of the task they are performing. 

With the exception of a minimal set of introductory online 
dociunentation. all help text is installed on the HP MPower 
server to conserve client disk space. More about HP 
MPower help is covered in the articles on pages 79 and 90. 

t Hyperlinks ate navigation pointers tD related pieces of information The online help article on 
page 90 provides more information about hyperlinks 
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Table I 

HP MPower Objects and Actions 



Object 


File 
Suffix 


Appropriate Actions in HP MPower 


SUNFILE 


au 


Create. Edit. Mail. Play 


NEXTFILE 


5nd 


Create. Edit, Mail. Play 


WAVFILE 


waw 


Create. Edit, Mail. Play 


L16F1LE 


J16 


Create. Edit. MaiL Play 


LSFILE 


.18 


Create. Edit, Mail. Play 


L08FILE 


JaB 


Create. Edit. Mail. Play 


ALFILE 


al 


Create, Edit, Mail. Play 


UFII.K 


u 


Create, Edit. Mail. Play 


PS 


ps 


View, Print, Mail. Fax 


EPS 


.eps 


View, Print, Mail. Fax 


TIFF 


tif. .tiff 


View. Print, Create, Mail. Fax 


GIF 


# 


View, Print, Mail. Fax 


JPG 


ipg. ipeg 


View, Print, Create, Mail, Fax 


BMF 


.bmf 


View, Print, Mail, Fax 


BM 


xbm, .bm 


View, Print, Create. Edit. Mail, Fax 


PM 


.xpm, pm 


View, Print, Create, Edit, Mail, Fax 


XWD 


xwd, wd 


View, Print, Create, Mail. Fax 


MIME 


.mim 


View, Print, Create. Edit, Mail. Fax 


Unknown 


link 


Create. Mail 


Data/Text 


(any) 


View, Print, Create, Edit, Mail. Fax 



Client/Server Architecture 

UP MPower is shipped in a client/server configuration, 
allowing applications and data lo lie distributed across a 
networked computing environment. In a client/serv er archi- 
tecture, programs and data are split across the network ac- 
cording to each machine's capabilities. The term server refers 
to a program offering a service such as faxing or printing. 
The term client refers to a program requesting a service, 
such as tlie fax composer or the HP SharedPrinl client. 

In loday's client/server world, many services are typically 
concentrated on a powerful central system, which is termed 
a server system. For example, the HP MPower server offers 
built-in fax, mail, font, help, print, and IIP VUE services. The 
functionality available locally on the user's desktop is col- 
lected on what we call the IIP MPower client. 

Advantages of the HP MPower client/server architecture 
include: 

Distributed processing 

Maximum performance measured by interactive response 
times and load balancing 

Minimum cost-per-seal realized by RAM and disk savings 
Scalability in thai when new clients are added, the system 
administrator can either add new servers or simply add 
RAM and disk to existing servers. 

Fig. (i shows a typical IIP MPower client/server configuration. 
In this configuration a client can fax a document via an IIP 
MPower server to another clienl (see 1 in Fig. (>). Likewise 
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Fig. 6. Faxing a document between two clients connected to different 
HI' MPower servers. 

a client can send a document to an HP MPower server (pro- 
vided it offers print services) lo be printed on a specific 
primer (? in Fig. 6). Typically, an IIP MPower server pro- 
vides fax, printer, font, online help, and user interface ser- 
vices. The HP MPower client provides local image process- 
ing, audio, video, and display services. Applications, such as 
spreadsheets, can nin on the server, on the client, or on 
dedicated application servers. 

HP MPower services can be split among a variety of ma- 
chines in extremely flexible configurations. For example. 
HP SharedPrint servers are installed on whatever machines 
have printers physically connected, the fax server can run 
on a machine different from the IIP MPower server, and 
there can be two or more HP VI 'E servers providing login, 
file, and window management services for a large group of 
users. However, in arranging services in such a manner an 
extra burden is put on the system installer and network 
administrator. 

For simplicity, the HP MPower server by default runs all the 
IIP MPower services. The HP MPower client on the user's 
desktop runs whatever productivity, multimedia, or user 
interface applications it can offload from the HP MPower 
server. 

Server Processes 

IIP MPower server processes include the device drivers and 
the interprocess communication software shown in Fig. 5. 
The server processes in the HP MPower 1.0 network include: 
An XI LR5 display server with IIP SharedX and video 
extensions 
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• An audio server that manages local audio hardware 

» A font server that manages the fonts on the IIP MPower 
server 

■ A fax server that manages local fax modems 

• A print server that manages local printers. 

These server processes enable client applications to access 
a serially reusable resource attached to a given host. Thp 
font server enables the HP MPower server to service font 
requests from all applications, affording significant disk sav- 
ings. The fax server handles file conversions (e.g., convert- 
ing from PostScript to fax-file formal), call routing, adminis- 
trative databases, and incoming and outgoing telephone 
connections. The print server employs a variety of filters to 
convert popular imaging formats to a given printer's native 
language. 

Descriptions of the audio, fax, and print server processes 
are covered in the articles on pages 62, 53, and 44, respec- 
tively. HP SharedX, which is a tool for sharing windows, is 
described in the article on page 23. 

Interprocess Communication Mechanisms 

HP MPower employs a variety of interprocess communica- 
tion mechanisms to enable its asynchronous, distributed 
processes to communicate and cooperate. UNIX* domain 
and internet sockets provide most of the substrate, enabling 
remote procedure calls and event-driven protocols. Helper 
processes include a remote invocation daemon for launch- 
ing distributed applications, a broadcast message server for 
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Fig. 7. The broadcast message server enables the fax composer to 
accept a dropped file from Ihe HP VUE 3.0 file manager. 

passing simple strings, a location broker daemon for estab- 
lishing connections, and other standard UNIX services (X 
server, name server, remote print daemon, NFS-mount 
daemon, and a mail transport mechanism). 

For example, in extending the HP VI E 3.0 drag and drop 
mechanism to the IIP MPower tools, the broadcast message 
server (BMS) provides the communication link (see Fig. 7). 

Desktop Configurations 

HP MPower provides four preconfigured desktop clients as 
shown in Fig. 8. For each configuration, Fig. 8 indicates the 
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I PostScript Viewer 
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HPVUE 

Icon Images 
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Multimedia File Converter 

X11R5 Server with Video and HP SharedX Extensions* 
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Scanner 

Image Viewer 

Audio Editor 

Audio Server 

Whiteboard Client 

HP SharedPrint Clients 

HP SharedX Client 

* This is the only component on an X station configuration. 
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Fig. 8. Different desktop configurations provided with HP MPower. (a) HP MPower services provided by clients and servers, (b) X station 
configuration, (c) Miniclient configuration, (d) Maxiclient configuration, (e) Client-on-server configuration. 
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approximate share of the HP MPower processing load that 
occurs locally on the desktop client before any other appli- 
cations are started. Fig. 8a shows the HP MPower services 
distributed among the configurations shown in Figs. 8b to 8e. 

X Station Configuration. In the X station configuration the user 
runs HP WE -3.0 and the media services totally from the HP 
MPower server (Fig- 8b"). There is no local processing, other 
than the display server portion of the XI 1R5 window display 
system. T HP 9000 Series 300 and 400 workstations and X 
stations and workstations from other vendors can function 
as HP MPower X stations. These stations will run the HP 
MPower software entirely on the HP MPower server (includ- 
ing the client services), but can run other applications locally 
on I he workstation. 

For more about X stations (or X terminals) see "X Stations 
in HP MPower" on page 16. 

Note that the media tool software architecture shown in Fig. 
5 is not applicable to the X station desktop configuration 
because with the exception of the display and audio driver 
software all software runs on the HP MPower server. 

Miniclient Configuration. On an HP MPower miniclient most 
media services, such as audio and imaging, run locally ( Fig. 
8c). The users HP VUE session, including the file manager 
and the window manager, runs on the HP MPower server. 

The miniclient configuration takes advantage of local HP-PA 
RISC processing power for imaging operations, such as 
rotation, scaling, and contrast. 

Maxiclient Configuration. On an HP MPower maxiclient the 
IIP VUE user interface and most media services can be ran 
locally (Fig. 8d). The advantage here is that the dependence 
on the IIP MPower server for the desktop user interface is 
removed. 

Client-on-Server Configuration. This configuration uses a fully 
loaded workstation, running both server and client HP 
MPower software (Fig. 8c). Essentially, it offers standalone 
media services suitable for both networked and nonnet- 
worked environments. 

This configuration is easiest to configure and administer, but 
it is the least cost-effective solution. Also, it is limited to 
computers thai support bitmap displays. 

Network Home 

To provide a consistent environment for users whose data 
files reside on one machine and applications on another, IIP 
MPower implements a network home environment. This 
environment provides the user with a view of files that is 
consistent across all machines in the HP MPower network. 
The user sees the same colors, fonts, home directory, and so 
on regardless of the HP MPower client or X terminal on 
which a session is started. 

To set up the home environment, system administrators 
have three options for locating users' personal data (i.e., 
SHOME directories): 

• Leave the SHOME directory on the user's desktop workstation 

• Place the SHOME directory on the HP MPower server 

t The new HP bNWEX X stations otter a local flexible disk drive, aodio. printing, and scanning 



• Place the SHOME directory on an alternate file server. 
Installation and Configuration 

Because of its complex interprocess interactions and client/ 
server architecture, HP MPower depends heavily on the 
functionality of the HP-UX operating system. For example. 
HP-UX scripts are used to customize HP MPower during 
initial installation when the HP Instant Ignition tt process is 
running. Scripts are also used to add. delete, and reconfigure 
HP MPower clients. 

Two of lite most important scripts, which are run at instant 
ignition boot time, are responsible for setting up the HP 
MPower server and HP MPower clients. The server configu- 
ration script (setup_server) performs the following functions 
of the server system: 

• Starts the network file system (NFS) for remote file access 

• Starts the NFS automounter service to provide transparent 
access to remote file systems 

• Starts the network computing system (NCS) to support 
remote printing, faxing, and audio 

• Starts the X 1 1 font server so that HP MPower clients can 
obtain t heir fonts from the HP MPower server system 

• Starts the sendmail daemon so that users can send and 
receive multimedia mail. 

The setup_client configuration script, which nuts on the HP 
MPower client, performs the following functions: 

• Enables NFS and automounter 

• Sets up links between the client and server for the local 
client file system 

• Establishes the fax, HP SharedPrint, and HP VUE 
connections to the HP MPower server 

• Enables the drag and drop capability between server and 
client. 

The system administrator can add or remove other clients at 
any lime by running a simple adminserver script on the IIP 
MPower server. 

Session Startup and Login 

At later system boots (alter the initial installation described 
above), the /etc/src.sh script sets certain key global environ- 
ment variables, such as the HP VUE server. On the HP 
MPower server, the /etc/rc file starts the fax server and the 
font server processes. Other boot-time scripts start the NFS, 
automounl. and HP VI IE login processes. 

When a the user logs in through the graphical HP MPower 
welcome screen, other variables such as the user's audio 
host, help path, and network home are established. 

Testing 

Because of the number of software components and hard- 
ware configurations, testing HP MPower was a daunting 
task. We concentrated on the configurations that would be 
most popular, as directed by our product marketing team, 
with particular emphasis on the IIP 9000 Models 712 and 715 
machines configured as standalone desktop clients, fit the 
course of the project, we used more than 20 integration and 
test machines internally to verify software installation and 
configurat ion. 

1 1 See "the HP Instant Igninon Program" on page 17 
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X Stations in HP MPower 

The X station lot X terminall is a product optimized to run X Window System server 
software X stations were developed when the X Window System was established 
as a standard distributed windowing system for the UNIX operating system. Three 
major factors accelerated the acceptance of X stations in fhe market 

• L-mergence of the client/server model of computing 

• Dramatic increases in processor compute power 

• Improvements in networking technology 

The X station is a network-based display device that uses X protocol over a local 
area network (LAN) to communicate with Ihe host. The programs specially written 
for X {called clients) run on the host but display their output on the X station. X 
stations are also able to run programs locally. The programs that run locally on the 
X stations are referred to as local clients There are three major classes of local 
clients local window managers, local terminal emulators, and local utilities. 

X stations cannot operate without a host because they use the compuie power, 
memory, and disk space af the host machine. 

X Stations versus Workstations 

The X station is a complementary product id the workstation in that it offers the 
look, feel, sound, and graphics performance of a workstation, but at a much lower 
price. Typically, the X station costs about half what the comparable workstation 
costs, while providing workstation-like graphics performance. X stations allow 
multiple users to access the power of a modern workstation (host), help to make 
better use of the compute power and disk space available on the network, and 
simplify system administration X stations are noi suitable for two types of users 

• Power users that run simulation and modeling programs 

• 3D graphics users. 

The reasons X stations are less expensive than workstations include: 

• They use a low-cost embedded graphic controller as CPU. A general-purpose 
processor used in a workstation is much more expensive. 

• They need much less memory to perform the same tasks since they have a com- 
pact, real-time, UNIX-system-like operating system that uses only a small traction 
of the DRAM required for a complete UNIX operating system 

• Most of their electronic circuitry is integrated into application-specific integrated 
circuits (ASICs) to reduce cost even further. 

• They use less power, making their power supplies less expensive. 

• They do not have any hard disks. 

Configuring X Stations in HP MPower 

X stations support all HP MPower functionality with the exceplion uf a live video 
input. X stations are not true HP MPower clients They require that both the HP 
MPower server and client run on the host. The newly introduced HP ENVIZEX 
stations support local audio, local scanner, local floppy diskette in DOS formal, 
and HP SharedX functionality as a sender and receiver The following additions 
are recommended to the .vueprofile file in a home directory for a user that uses an 
X station and the HP MPower software 

I AUDIO and SCANNER variables are derived from DISPLAY variable to ensure 

- that muluple X stations can support local audio and local 

t scanning while running HP MPower software on the same host 

xterm_name=S(echoSDISPLAY I sed 's;:.\;'l 

SCANNER=Sxterm_name 
export SCANNER 

AUDIO=Sxterm_name:0 
export AUDIO 



#SPEAKER=INTERNAL 
SPEAKER=EXTERNAL 
export SPEAKER 



# uncomment if there are no external speakers 
» comment out if there are no external speakers 



Initially, our strategy was to support as small a number of 
configurations as possible and to increase thai number with 
each subsequent product release. We began by providing 
support for the Series 700 only. With HP MPower 1.2 we 
expanded that base to include the Series 800 as HP MPower 
servers, the Series 300 and 400 as HP MPower X stations, and 
the new ENVIZEX X stations as media-enabled X stations. 
Similarly, our first release was English only; HP MPower 1.2 
added support for . Japanese and lfi-hit character sets. 

The team provided an alpha release to a select number of 
customers, which was hand-delivered and installed by a 
support group from the factory. We also created two sepa- 
rate beta releases to flush out installation and configuration 
problems. More than 40 internal HP sites installed early ver- 
sions of the software. Our goal was to minimize the amount 
of time required to install more than 30M bytes of software. 

Two usability tests helped shape the user interface of Ute 
system. We learned early that the user interfaces of the indi- 
vidual components had to change to fit Ihe overall user in- 
teraction with the system. For example, all components 
adopted a uniform file selection dialog to enable users to 
access and save files consistently. 

A system administration walkthrough resulted in installation 
and documentation adjustments, particularly in organizing 
the system installation into separate procedures for instant 
ignition and noninstant ignition systems. The prerelease 
feedback enabled us to cut the installation time from two 
weeks (at the project outset ) to two days (at alpha release) 
to two hours (for the final product). 

We divided testing responsibility among the component 
owners so that one team tested the fax. imaging, audio, and 
other media components, another team tested the HP 
SharedX and whiteboard components, and a third team cov- 
ered Ihe mail, desktop integration, and system installation 
areas. We relied extensively on an automated defect track- 
ing system for monitoring defect levels and resolution rates 
on a weekly basis. 

We performed a limited set of code inspections on new and 
critical modules. Team members spent many hours testing 
the components and system interactions manually. They have 
since stalled work to automate a number of these tests. 

Diagnostics 

HP MPower has a diagnostic facility called Dr_MPower which 
consists of a variety of submodules that check dozens of key 
system and personal files to ensure that the system and the 
media services are properly installed and configured. 
Dr_MPower can be run on either a server or a client. 

Users can run Dr.MPower simply by double-clicking the tool's 
icon in the file manager toolbox. See the article above for 
more about this diagnostic. 

Challenges 

Besides working on a tight schedule, some of the challenges 
we encountered while developing the first HP MPower 
product included: 

(continued on page 181 
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The HP Instant Ignition Program 



The HP Instant Ignition program is focused on increasing customer satisfaction by 
delivering a complete, integrated, preconfigured systemt that is ready to use The 
program has the following goals 

• Give the customer a positive 'out of the bo*' experience li e . a positive first 
impression of our systeml 

• Decrease the "time to productive use" of a system 

. Oecrease HP's field and factory cost by using common tools and standardized 
processes 

What Is an Instant Ignition System? 

Tne HP Instant Ignition system is made up of the basic computer system hardware, 
including a disk that is preloaded with an operating system, optional application 
software, and system documentation. 

The HP Instant Ignition design team set out to make HP 9000 systems less intimi- 
dating to the user. The team designed a number of usability enhancements aimed 
at addressing the program goals. For example, esoteric messages were removed 
from the boot process The team replaced other messages with a concise checklist 
that indicates passing or failing portions of the boot procedure (Fig 1 1 labels on 
boxes were enhanced to make them more readable 

Additionally, the first time the system is booted, the user is prompted to provide 
system parameters that cannot be predicted in the factory, such as networking 
specifics This method of configuring the system eliminates the need for a user lo 
edit files manually. 

The HP MPower team designed an extension to these system parameter prompts. 
The links between the client and server are established as the system is booted so 
that HP MPower is fully functional the first time any user logs into the system 

CHAMP 

To preload the various operating systems and applications, the instant ignition 
team developed a software tool called CHAMP (channel-reseller and manufac- 
turing process). CHAMP fits into an automated hardware manufacturing line al a 
point where the CPU is assembled with a disk and diagnostics have successfully 
completed. At this point, the customer's disk is ready to be built using a two-phase 
process. 

First, the customer's CPU boots (rom a dedicated manufacturing disk that contains 
the CHAMP tool CHAMP runs on Ihe customer's hardware and downloads the 
operating system to the customer's disk or target disk CHAMP then downloads 

t Currently HP 9000 Series 700 and 800 machines 



HP-UX S lan-up In Process Status 

Initializing System I OK ] 

Starting Networking ( OK j 
Starling Diskless Cluster Client ( OK 1 

Starting System Functions [ OK ] 

Starling Auditing I OK ) 

Stalling Diagnostics I OK ) 

la) 

HP-UX Start-up In Process Status 

Initializing System I OK ] 

Starling Networking I FAIL I* 
Starting Diskless Cluster Client 1 OK ] 

Starting System Functions [ OK ] 

Starting Auditing I OK I 

Starting Diagnostics [ OK j 



NOTE: An error has occurred! 

Refer to the lile /usr/adm/rc.log lor more information. 

Press [Return] to continue 

(bl 

Fig. 1. An HP Instant Ignition boot checklist la| When things are OK (b| When things are 
not OK 



some utilities to the target disk to prepare for phase two The last thing to occur in 
phase one is to reboot the customer's system. 

In phase two. the customer's system boots from its own disk, the target disk 
created above If necessary, instead of booting to the login screen as expected 
the system runs the utilities downloaded in phase one to fetch additional soft- 
ware This software may come from a netdist server or from another system on the 
network The system will also configure its kernel, if necessary, based on the 
customer's hardware and optional software 

The last thing to occur during a CHAMP build is to remove the CHAMP utilities and 
return the operating system to a pristine slate The system then shuts itself down 
and is ready for the customer 

Design Considerations 

In designing CHAMP, a number of requirements had to be met Some of the key 
design requirements were to: 

• Preload HP 3000 Series 700 and Series 800 HP-UX operating systems 

• Run from a command line, allowing existing manufacturing processes to invoke 
CHAMP automatically 

• Run on the customer's hardware (This guarantees that the HP-UX kernel and the 
recovery instructions are specific to the customer's hardware.) 

• Load application software that is delivered in a variety of formats (HP's preferred 
method for packaging software is update foimat The utility /etc/update is a stan- 
dard part of the HP-UX operating system and is available to internal and external 
customers. CHAMP is flexible enough to load software in other formats, such as 

tar and cpio.) 

• Load software in sequence (This means that if application 1 must be loaded be- 
fore application 2, CHAMP can accommodate this sequence.) 

• Generate customized recovery instructions for each system (These instructions 
outline exactly how the system was created in manufacturing so that the customer 
can recreate the original system in the event of a disk failure. These instructions 
are online in a file, and a hard-copy version is added tu the shipping boxes at the 
final stage ol the manufacturing process.) 

Other Uses for CHAMP 

It became evident that CHAMP had potential uses outside of HFs manufacturing 
process. For instance, resellers could be more effective in delivering HP Instant 
Ignition systems if they had access tu CHAMP and if CHAMP was easy to use and 
maintain. 

While flexibility is one of Ihe outstanding features of Ihe CHAMP tool, flexibility 
does not always equate to ease of use To enhance usability, a graphical user 
interface was layered onto the basic CHAMP tool With this interface, CHAMP is 
very easy for the nonexpert, such as a reseller, to use to build preloaded systems 
quickly. 

CHAMP is also used by operating system and application developers internal to 
HP These developers can use CHAMP to build a test system for their development 
It takes about 30 minutes tu create a new HP-UX system using CHAMP This is 
considerably taster than using CD-ROM media to build a new system. All HP teams 
that develop pieces of the HP-UX operating systems and preloaded applications 
are required to test their software on the base system built by CHAMP 

Conclusion 

Customer acceptance and popularity of the HP Instant Ignition program continues 
to grow. Customers like to receive their systems with preloaded software Today 
the HP Instant Ignition program is limiled tu preloading HP applications because of 
internal issues related to selling and preloading third-party software. 

Sue Magenis 

Development Engineer 

Open Systems Software Division 
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Diagnosing and Reporting Problems in the Multimedia Environment 



The need lor installation and configuration diagnostics lor user interface software 
became apparent soon after the release of HP VUE 2.0. Because of the large 
number of files associated with HP VUE and the dissemination of those files 
across the file system, response centert engineers were spending a lot of time 
telling customers about which files to check for known problems An analysis of 
call-in data from the Atlanta response center revealed that ihe amount of time 
spent each quarter handling HP VUE configuration questions was rising rapidly 

As a result of this feedback, the technical training and support group in Corvallis 
decided that a script or program could more efficiently wander the highways of 
the file system and check on the existence, permissions, and ownership of most of 
the files that HP VUE depended on Key files, such as /usr/adm/ineld.sec, /etc/ininab, 
and others could be searched with standard tools to determine if the attributes 
required for certain entries were proper. The use of a script could reduce the 
amount of time required to check basic configuration issues from hours or days to 
a matter of a minutes Thus. Dr_VUE (diagnose and report Visual User Environment 
problems) was born 

Dr_MPower is a direct outgrowth of Dr.VUE Dr_MPower consists of a collection 
of diagnostic tools used lo help debug installation and configuration problems in 
the HP MPower environment Since HP MPower combines several disparate appli- 
cations, we decided to create a separate script to check each individual compo- 
nent This resulted in a total of 12 scripts one each for 10 components of HP 
MPower, a file that contains common functions used by each of the scripts, and a 
calling script. The calling script is Or_mpower, which does some checking of sys- 
tem functions and then calls each of the remaining scripts in turn Since HP 
MPower makes heavy use of the HP VUE environment, an action was defined to 
initiate Dr^MPower This action is located in one of the toolboxes available to all 
users. A simple double-click on the Dr_MPower icon results in a new terminal 
window that displays the information output by Dr_MPower. Each of the scripts 
called by Dr_MPower can also be run individually to perform checking on the 
separate components of the HP MPower environment. 

A myriad of configuration issues exist in the HP MPower environment Dr. MPower 
certainly does not check each and every possible one, but rather looks at what we 
hope to be the vast majority of them Since the MPower environment consists of 
servers, maxiclients (clients running HP VUE locally), mmiclients (clients running 
HP VUE on the server), and X terminals, the first thing that Or_MPower needs to 
determine is the type of system it is running on. When this has been accom- 
plished, Dr_MPower will check items specific to that environment For example, 
there are differences between the client and the server in recommended kernel 
parameters, as well as certain processes that run on the server and not on the 
client Another difference is the fad that the miniclient does not run HP VUE 

I HP has several locations worldwide thai are responsible lor handling soflwaie or hardware 
prublems horn customers who have purchased response-line suppun conliacts These 
locations are called response cenrers. 



• Geographically separated learns. The I IP MPower project 
team included members from Oregon, Massachusetts, 
California, Colorado, and Canada. Keeping the lines of com- 
munication open and efficient helped us understand some 
of the requirements of distributed work groups. 

• Integrating disparate components. Initially, team members 
designed their products (such as fax and whiteboard) as 
standalone applicat ions. Achieving a common look and feel 
involved changing parts of our HP MPower subsystems 
such as interprocess communication mechanisms, icon 
visuals, online help, and dialog box behavior. 

• Incorporating a common file-typing mechanism. The HP-UX 
file system is designed to treat all files simply as bags of 
bytes. Within a graphical user environment, it is necessary 
to know file types to determine the appropriate actions for a 
given object (e.g.. mail, print, edit, fax, play, and view). To 
preserve the file types of HP MPower media objects, we 



locally, so the check_vue script that is called by Dr_MPower should not be run for 
that platform 

The installation and configuration of HP MPower makes heavy use of scripts, and 
since scripts fail occasionally. Dr_MPower attempts to verify that all the actions 
performed in the various configuration scripts have been accomplished. An exam- 
ple is checking in the file /etc/netnlsrc to see if the parameters NFS.. CLIENT, 
NFS. SERVER, and START MOUNTO were successfully set to one by the configura- 
tion scripts. Another example is checking to see that a line was added in /etc/rc to 
start the font server and that the font server is currently running. Fig 1 is a graphical 
representation of the components checked by Or_MPower 

Anytime Dr. MPower encounters something that appears to be in error, a message 
is written that attempts to inform the user as to the severity of the problem with 
either INFO. WARNING, or ERROR statements (similar to the feedback seen in an 
update log) If possible, an appropriate course of action is also given. For example, 
a check is made uf the /etc/src.sh file lo determine if the configuration script 
added two entries specifying the HP MPower and HP VUE servers The following 
code performs this check and issues a WARNING statement if the installation 
script did not add the entries in the /etc/src.sh file: 

## look in /etc/src.sh to see if VUE_ SERVER and MPOWER. SERVER were 
tt added 

count=Sgrep -o VUE.SERVER -e MPOWER SERVER /eic/src.sh I wc-l| 
I Scount — eq 2)11 

prim "WARNING:The MPower installauon script should have added 
two entries lo /etc/src.sh: 
VUE_SERVER=Shostnamo; export VUE. SERVER 

MPOWER_SERVER=Shostname; export MP0WER_SERVER 

This does not appear to be the case. Vou should rerun ihe 
/usr/MPowerServer/setup_server script or add these 
lines yourself." 

This code performs the check and provides the user with two options to correct 
the perceived problem, either manually add the entries or rerun the configuration 
script that should have made the additions 

There are over 4000 lines of code in the various scripts that make up Dr_MPower 
Considering the positive feedback we have received from support partners con- 
cerning Dr_VUE, we are confident that the Dr_MPowar scripts will significantly 
reduce the time spent supporting customers with HP MPower problems. 

John V. Peterson 
Support Engineer 
Workstation Group/Corvalhs 



implemented a variety of file-typing mechanisms, ranging 
from appending file name suffixes to inspecting file contents. 

• Living within workstation resources. OSF/Motif applications 
BIG quite large. Thus, running a variety of OSF/Motif-based 
applications and a myriad of server and helper processes on 
limited-memory systems forced us to adopt a client-server 
architecture. 

• Large media objects. Media objects are by nature large. For 
example, a sound clip can cost ItiK bytes per second, and 
each video frame can cost almost a megabyte. We use a 
number of compressed file formats to keep file sizes to a 
minimum such as the JPEG file format for video images. 
Fortunately, the processing power of the HP PA-RISC-based 
workstations makes the compression and decompression of 
media objects a fairly painless process. 

• Configuring ihe distributed environment. System adminis- 
tration burdens can grow exponentially when services are 
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check sprint 



BlMkJn 



checfe_scan 



check image 





check video 



check_sharedX 




Fig. I. The HP MPower components checked 
by Or.MPower and the associated scripts 
responsible lor making the checks 



distributed over several hosts. By offering a fairly restricted 
default configuration, we have reduced the headache of 
installing and maintaining HP MPower nodes. 
1 Living in the network home. Today's users are familiar with 
desktop) computing, in which most of their applications and 
data reside on their local machine. When their environment 
is distributed across multiple hosts, users can become dis- 
oriented in the network environment. We have tried to make 
file access as transparent as possible and to invoke applica- 
tions on t he expected host. 
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A Graphical User Interface for a 
Multimedia Environment 



The HP Visual User Environment, or HP VUE, provides not only a friendly 
user interface to the HP-UX* operating system but also a framework for 
the HP MPower system. 

by Charles V. Fernandez 



Ii was inevitable thai once the multitasking, multiuser, and 
network capabilities of the UNIX* operating system were 
connected with the power ol" graphics workstations that I lie 
next step would be lo civilize I he I'NIX command line inler- 
face with a graphical user interface (GUT). Graphical user 
interfaces are literally changing the face of UNIX systems, 
and in doing so, are helping to spread UNIX systems and 
workstations from their lustorieal installed base among tech- 
nical users into the broader markets offered by commercial 
computing. 

Among these GUIs is the III' Visual User Environment 
(HP VUE). HP VUE is the Erst GUI to provide the following 
features and capabilities for workstations running the 
HP-UX operating system: 
PC-compatible controls 
3D visual appearance 

A graphical user interface to the system's particular 
functionalities while hiding the peculiarities of the system 
from the end user 

Multiple levels of integration for in-house and ISV 
(independent software vendor ) applications. 

As the framework for HP MI'ower, HP VUE provides the 
structure into which multimedia components can be 
integrated. 

HP VUE provides a consistent set of controls with which to 
operate a workstation. While UNIX system commands con- 
tain a lot of functionality, this functionality is often cryptic, 
hard to understand, and difficult to remember, especially for 
occasional users. Additionally, UNIX system commands and 
their options ar e often inconsistent (some commands provide 
output, others don't, and what an -o option means depends 
on the command, not the functionality of the option ). HP 
VUE changes all this. IIP VUE uses a simple set of graphical 
controls, consistent with the Common User Access (CUA) 
model followed by Microsoft," IBM Corp.. and many other 
PC manufacturers. The CUA model is based on pushbuttons, 
scroll bars, and menus. 

A user familiar with similar controls such as Microsoft 
Windows can sit down at a workstation with an IIP VUE 
user interface and immediately take control because the 
skills required to operate a PC GUI are the same as the skills 
needed to operate an HP VUE workstation. 

To operate a UNIX system from the command line, a user has 
to type commands and command options at the keyboard. A 



spelling mistake or a typing error could mean disaster. Com- 
mands, unless memorized, have to be looked up in the docu- 
mentation. HP VI "E unburdens the user from having to 
memorize UNIX commands and retype faulty command 
lines. To operate an HP-UX system from IIP VUE, a user 
directly manipulates the graphical objects that populate the 
workspace. For example, to move a file from one directory 
to another, the user drags the file icon from one file manager 
view to another and drops it there. To start an application, 
die HP VUE user double-c licks the application icon. 

One of the confusing things for users of an operating system 
is that they are required to develop a three-tiered level of 
consciousness: one level for the operating system, one for 
the application, and a third for their data the only tier they 
are really interested in. New users have a difficult time dis- 
tinguishing where one level stops and the other stalls. Com- 
mand line environments routinely demand that a user who 
wants to access data must sw itch from a data focus, remem- 
ber which application works with that data (and possibly 
where that application is located), and negotiate how to 
start the application. Only after successfully starting the 
application can the user return to the desired data focus. 

HP VUE, on the other hand, because it associates applica- 
tions with data using an action and file-typing function, en- 
ables users to remain focused on their data, and the operat- 
ing system and application tiers remain hidden by the user 
interface. To access data in the HP VUE environment, users 
double-click the data icon. The application starts automati- 
cally and loads the selected data file, leaving the user free to 
focus on work, not the mechanics of getting to work. 

The HP VUE 3.0 Design Process 

Getting HP VUE to its current state has been an evolution- 
ary process. The process began in the mid-1980s when HP 
adopted the X Window System as the strategic graphical 
layer for workstations. This evolution continued through the 
development of the 3D window manager, hpwm. its submittal 
and acceptance by the Open Software Foundation (OSF) as 
an industry standard, the proliferation of OSF/Motif, the 
development of HP VUE 2.0, and finally, HP VUE 3.0. 

During the design process of HP VUE 2.0 it became apparent 
that designing a user interface without user input would be 
a recipe for disaster. For the development of HP VUE 3.0. a 
more formalized approach to user input was established. This 
approach goes by the acronym QFD, for Quality Function 
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Deployment- 1 It was adopted for the development of HP 
VUE 3.0 to help ensure that 

• Customer input was systematically collected 

• Customer input was quantified to define and prioritize 
product requirements 

• Customer input was factored into the design process 

• Product design was affected by the input as opposed to the 
input Iwing interpreted to fit the design. 

The QFD for HP VUE 3.0 was a multistep process. Keeping 
in mind that the primary target market for HP VUE consists 
of workstation users, we established a target design market 
for HP VUE 3.0 in the areas of factory floor operations, 
scientific research, industrial and architec tural design, infor- 
mation engineering (knowledge workers), design engineer- 
ing, education, CASE (computer-aided software engineer- 
ing), and system administration. These design markets were 
given relative weights to facilitate the prioritization of their 
inputs. For example, input from scientific research with a 
weight of 5% wasn't nearly as influential as input from a 
knowledge worker with a weight of 35%. Within these areas, 
potential users were categorized on a L'NIX knowleclgeability 
spectrum that included categories for protected users, naive 
users, moderate* users, and sophisticated users. Correlations 
were noted between these user types and our target design 
market. Over 30 companies were visited and asked to input 
into the HP VUE 3.0 QFD process. 

The result was a weighted list in priority order of what cus- 
tomers wanted. Performance figured high on the list. Pizzazzt 
was also important. Of less importance were multiple fonts 
and workspac e manager button labels. This list essentially 
formed a prioritized functional specification wish list for the 
HP VUE 3.0 product. 

The Workspace Manager 

HP VUE 3.0 workspace manager has a new look that differ- 
entiates it from HP VUE 2.0. This new look is part pizzazz 
and part pragmatism. The pizzazz is that the square button 
look of the 2.0 front panel is replaced by a "membrane" look 
in which the bevels clemarking the buttons are removed and 
the icons that form the button labels appear inset into the 
front-panel membrane. 

Pig. 1 illustrates the familiar "boxy" look of the IIP VUE 2.0 
front panel and the new and improved membrane look of the 
HP VUE 3.0 front panel. Notice also the slide-up subpanels 
available with the HP VUE 3.0 front panel. The tall subpanel 
on the left is the HP MPower media panel. HP VUE 3.0, as 
mentioned earlier, provides the framework for IIP MPower. 

Aside from supplying an easily recognizable visual distinc- 
tion between the two versions of IIP VUE, the membrane 
look makes the front panel easier to configure. To place a 
button in the old front panel required users to count the 
length and width of a button in pixels and then add pixels 
for the bevels. This proved to be a time-consuming and 
error-prone activity and certainly not user-friendly. The 
membrane look eliminates the need for users to count pixels. 
They simply specify the button, and the front panel magically 
grows itself to fit the new button. 

t ?\mu retetr, in ihose lealuies in a product that might create cuslomei excitement ley . 
garhage can Icon that open when Hash ir, tossed in at button icons that look and behave 
like real pushbuttons! 




Fig. I. (a) The "iKixy" look of the HP VUE 2.0 front, panel and 
(li) the new and improved membrane look of the HP VUE 3.0 front 
panel including the HP MPower slide-up subpanel on the left. 

Another pizzazz and functional feature of the new front 
panel is the inclusion of slide-up subpanels. These panels 
slide up seemingly from behind the front panel when their 
control is pressed. The slide-up subpanels enable developers 
to make more controls readily available without taking up 
more space. They also provide a convenient place to locate 
the multimedia components of IIP MPower. The slide-up 
Subpanels Can be torn off and posted to the workspace like 
a control panel. 

The File Manager 

The file manager is a good example of how QFD and usability 
studies can refine a product. HP VUE 2.0 packed a lot of 
functionality into the file manager. Virtually all system file 
management was available through the file manager's GUI. 
This is a good thing. However, what the 2.0 file manager 
didn't do, and what QFD and usability studies made apparent, 
was thai all that functionality wasn't readily accessible. 

The best example of this is the process of renaming a file. To 
rename a file in HP Vl'E 2.0, the user had to do the following: 

• Select the file to be renamed 

• Pull down the File menu 

• Select Rename from the menu 

• Wait for the Rename dialog box to appear 

• Click the Rename text entry field in the dialog box 

• Type the new Tile name 

• Click the OK button. 

As a result of feedback from QFD and the usability studies, 
the HP VI IE 3.0 file renaming process involves the following 
steps: 

• Click on the file name to change 

• Type the new name 

• Press the Return key. 
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Visually, the file manager didn't change that much bet ween 
III* VUE 2.0 and HP VUE 3.0. However, the difference in ease 
of use and accessibility to file management functionality is 
quite significant. 

The Style Manager 

The HP VUE 3.0 style manager is another component that 
shows the subtle but. unmistakable signs of the QFD pro- 
cess. While the work environment at HP is fairly open and 
users are fairly knowledgeable about the UNIX operating 
system, some of the system administrators and managers 
from customer sites often had more controlled environ- 
ments for security reasons. Their feedback was the impetus 
for removing the Host dialog from the style manager. They 
wanted control over the X Window System's ability to host 
"foreign" workstations. Also, for security reasons, they 
wanted to control the ability of one workstat ion to host 
other workstations. 

Along the same lines, security-conscious QFD participants 
requested that the little lock icon that appears on a locked 
workspace be changed to a full screen cover so that a 
passerby could not read information visible in the windows 
left open on the workspace. 

Performance 

Talk about graphical user interfaces long enough and 
eventually the discussion will get around to performance. 
Since HP VUE 2.0 is the most visible part of the operating 
syst em, it bore the brunt of a lot of negative performance 
comments. 

Some of these criticisms, like "HP VUE is a big memory 
consumer because it takes up 16M bytes of RAM," are un- 
deserved. HP VUE isn't, really a heavy memory user, but to 
many users it may seem to be so. On a typical workstation 
with I6M bytes of RAM, the RAM is apportioned roughly as 
follows: 

Miscellaneous Daemons 3M bytes 
File Buffers 3M bytes 

Kernel 3M bytes 

X Server 2M bytes 

Workspace Manager 1 M byte 

File Manager 0.75M byte 

Help Manager 0.75Mbyte 
Style Manager 1M byte 

llpterm Console 0.75M byte 

Message Server 0.5M byte 



Total 



15.75M bytes 



Nearly three quarters of the KiM bytes HP VI !E is suppos- 
edly hoarding is actually being used by core system func- 
tions. The point that is most often misunderstood about HP 
VI "E is that it is not a monolithic application, but a set of six 
components, not. all of which need to be running at the same 
time. When something isn't running or being currently used, 
it is pushed out of RAM. As a matter of fact, at a minimal 
level, the user can run the workspace manager and receive 
the benefits of multiple workspaces for little more cost in 



RAM than would be experienced with using a standard 
OSF/Motif window manager. 

One of the criticisms that HP VUE does deserve is for the 
amount of time it lakes to log in. For IIP VUE 3.0, perfor- 
mance, as mentioned above, was a key design area. Besides 
speeding up the access to functionality like renaming files, 
which increased perceived performance, all HP VI IE compo- 
nents and major processes were studied, including login, log- 
out, file management, and session management. Customers 
were asked what trade-offs in func tionality would be accept- 
able for the sake of better performance. Out of this research 
came a number of improvements. Instead of starting all HP 
VUE components immediately at login, their individual 
starts are staggered. Studies showed that starting processes 
all at once caused tremendous contention for RAM, while 
actually delaying a component's start until the preceding 
component was fully started. This staggered start of all 
processes reduced overall startup time. 

Another result of the HP VUE 3.0 performance work was 
the development of a lighter-weight version of HP VUE. 
This lighter version of HP VUE has two of the most RAM- 
expensive components removed: session and file manage- 
ment- Reliance on a default HP VUE session instead of true 
session management speeds up the login and logout pro- 
cesses. Using the file management functions available on the 
file menus of all standard OSF/Motif applications instead of 
l he IIP VUE file manager avoids session slowdowns caused 
by the Tile manager's periodically jumping into RAM (and 
pushing the resident application out) to check that its file 
views match the current file structure. 

Conclusion 

One of the most gratifying results of the HP VUE 3.0 QFD 
effort was the affirmation from customers of our belief t hat 
a GUI is a work in progress, an evolutionary process. Dra- 
matic differences between HP VUE 2.0 and HP VUE 3.0 
were both uncalled for and unwanted. What customers did 
want was evolutionary changes, such as to make it easier to 
rename a file and configure the front panel. Our QFD cus- 
tomers were very attuned to I IP VUE as an environment 
from which to access their working applications. Under- 
standing their vision enabled us to take the next step in HP 
VUE's evolution: making HP VUE the framework for HP 
M Power. 

Reference 

1. S. Graves, W. ('arniichael, D. Daetz, and E. Wilson, "Improving the 
Product Development Process," Heirlel I -Packard Journal, Vol. 24, 
no. 3, June 1991. pp. 71-76. 

HP-UX is based on anil is compatible with UNIX System Laboiatoties' UNIX* operating system 
It also complies with X/0pen's* XP63, P0SIX 1003 1 and SVID2 interface specifications. 
UNIX is a registered trademark of UNIX System laboratories Inc m the USA and other counties 
X/Open is a trademark ot X/Open Company Limited in the UK and other countries. 
Microsoft is a U S registered trademark of Microsoft Corporation 
Windows is a U S trademark of Microsoft Corporation 

OSF/Motif is a trademark of the Open Software Foundation m the U S and other countries 



22 April 1994 I Ipwiell-Packard Journal 



© Copr. 1949-1998 Hewlett-Packard Co. 



HP SharedX: A Tool for Real-Time 
Collaboration 



With this real-time communication product, two or more remote users can 
share and interact with the same X-protocol-based applications from their 
workstations. Windows are shared in such way that it almost seems as if 
all the participants in the shared session are sitting at the same 
workstation, running the same application. 

by Daniel GarHnkel, Bruce C. Welti, and Thomas W. Yip 



HP SharedX is a communication tool thai extends the 
industry-standard X Window .System to enable real-time 
sharing of X-protocol-based applications between two or 
more remote users and displays. With HP SharedX users can 
share information with one another via a workstation with- 
out being in the same location. 

Being able to share information over a network in real time 
is a very effective productivity tool. The following two ex- 
amples show how displaying applications across a computer 
network can increase productivity: 

• System administration. Mary is a system administrator for 
several networks distributed over several widely dispersed 
buildings. When a user on a particular network encounters 
what may be an application or system problem, Mary can, 
with the user's cooperation, establish a common (HP 
SharedX) window with the user's system. With this shared 
window Mary can see and diagnose the user's problem 
while the user is watching what she is doing. She can per- 
form this lask without leaving her desk, using the diagnostic 
tools available at her workstation. 

• Remote demonstrations. For some new or complex software 
packages, there may be only a handful of people who are 
able to demonstrate the soft ware effectively. HP SharedX 
gives these people an opportunity to have a virtual presence 
at. remote locations on the network. I lewlett-Packard's Work 
Management Operation routinely uses HP SharedX to dem- 
onstrate advanced features of its HP WorkManager data- 
base product from the desks of engineers in Fort Collins, 
Colorado to prospective buyers all over the world. Also, 
various partners who are developing additions to Work- 
Manager use HP SharedX to demonstrate their work in 
progress to the engineers in Fort Collins, allowing new 
features to be evaluated "live" without travel. 

HP SharedX can accomplish display sharing because of the 
nature of the system it is built upon, the X Window System. 1 •-' 
The X Window System, known simply as X, is a networked 
window system allowing X applications running on one 
computer to display on another (see "X Window System 
Client/Server Architecture" on page 25). This networked 
aspect allows sharing of expensive high-speed computers 
among several users on low-cost X-based display stations. 



Furthermore, X is designed to be interoperable in heteroge- 
neous computing environments. Applications running on one 
vendor's hardware can display themselves on another ven- 
dor's display by adhering to the X protocol standard. Hetero- 
geneity is accommodated by abstracting the application's 
view of the display subsystem, including the graphics hard- 
ware, input device control, memory management, and data 
formats. Interaction with the display station occurs through 
a well-defined protocol, which provides a consistent way for 
applications to work with a wide variety of display devices, 
from PCs to high-resolution, deep-color workstations. 

X has become the industry standard window system for 
workstat ions in part because of its networked and heteroge- 
neous nature. HP SharedX builds on the X Window System 
by retransmitting the X protocol stream to multiple X display 
stations, thus simultaneously displaying a single application 
on multiple computer displays. Some key features of HP 
SharedX are: 

> No changes are needed to existing X applications to share 
them. HP SharedX allows users to share virtually any X ap- 
plication, rather than forcing users to use specially written, 
collaborative applications. 

• Users see a copy of the application to the best ability of 
their display device. If necessary, HP SharedX will degrade 
the quality of the displayed images to match the capabilities 
of the display hardware. 

• Running applications can be shared without prior setup. 
Users need not restart applications they want to share; the 
application can be shared in its current stale. This is impor- 
tant in consulting environments where users may not know 
how they got their application into its current slate. 

• The receiving machines (machines receiving the shared 
application) need no modifications or special soft ware 
installed. Since X protocol is the communication mecha- 
nism, the receiving machine can be any X-capable display 
device. 

• Receivers of a shared application can interact with it as well 
as the sender (the machine sending the shared application). 
Receivers can demonstrate operation of the application 
rather than describing to the sender what to do. 
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Fig. L HP SltiirorlX sender/receiver architect ure and data flows during initial display connection. 



The rest of this article covers the architecture of the HP 
SharedX system, the user model and user interface for shar- 
ing, an overview of the low-level mechanism that multicasts 
the X protocol and merges input events, and finally, a de- 
scription of how sharing is accomplished with displays of 
different visual lypcs and different resources. 

HP SharedX Architecture 

HP SharedX consists of three components: the HP SharedX 
user interface (known as the connector), the HP SharedX 
receiver service, and the IIP SharedX extension to the X 
server (see Fig. 1 ). The connector is the sender's control 
for sharing and unsharing windows, enabling and disabling 
receiver input, displaying sharing status, and so on. The re- 
ceiver service is an optional process on the receiver's ma- 
chine that simplifies sharing windows and increases security. 
The IIP SharedX extension is a low-level mechanism that 
shares windows, keeps those windows up to date, and 
merges input from multiple users. These three components 
are described in more detail later. 

An IIP SharedX session begins when the user at the sending 
workstation specifies a receiver and pushes the Share button 
in the IIP SharedX connector window (Fig. 2). After the Share 
button is pushed the sender selects the window to share by 
clicking the mouse button over the desired window. Once 
the desired window is selected the following events occur 
between HP SharedX processes on the sender and receiver 
workstations shown in Fig. 1. Each step corresponds to a 
number circled in Fig. 1. 
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Disconnect 



Fig. 2. The IIP SharedX connector window. 
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X Window System Client/Server Architecture 



The X Window System, commonly referred to as X. is an industry -standard, network - 
transparent window system X presents to the user a hierarchy of resizable over- 
lapping windows providing devee independent graphics A graphical user interface 
is commonly included as an integral pan of the X Window System 

The principal feature that distinguishes X from a conventional window system is 
its network transparency The X Window System allows window applications or 
clients to access the display only through the X server, which is a separate process 
that arbitrates resource conflicts and provides display, keyboard, and mouse ser- 
vices to all clients accessing the display {Fig. 1 ) X can support a spectrum of 
hardware displays ranging from small monochrome units to advanced graphics 
systems with up to 32 bits of color per pixel 

The client and the server exchange information only by means of the X Window 
System protocol which can be implemented via any reliable byte stream In the 
HP-UX" implementation of X. as in most others, this byte stream is implemented 
as a socket, which is a logical data connection between two processes on the 
network Clients may reside locally with the display server or on a remote system 
across the local area network (LAN) A performance optimization bypasses the 
physical LAN when the client and the server are on the same computer 

Because the client program and the display server are two separate entities, the 
target display can be specified at the time the application client is run The client 
program is indifferent It sends out X protocol commands via calls to the X library 
(Xlib), which in turn calls the network service functions to communicate with the 
target X server 
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Network Services 
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Fig. t. X Window System client/server architecture 



1 . The connector sends a message over the network to the 
IIP SharedX receiver service on the receiver's machine. The 
receiver service displays a window asking the user at the 
receiver system to accept a shared window from I he sender 
(Fig. 3). 

2. The receiver passes hack a yes or no response to the 
connector. IT the answer is no, the sender is informed dial 
access is denied to the receiver's machine. 

3. If the answer is yes (or if Ihe receiving machine does not 
have the receiver service), t he connector sends a special X 
protocol request (share window W to receiver Ft2) to the 
sender's X server. The X server's main event loop recognizes 
the share window request as one directed at Ihe HP SharedX 
extension. It calls the appropriate function in the extension 
to handle the request 
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4. The IIP SharedX extension opens a connection over the 
network to the receiver's X server. This is done with the Xlib 
call XOpenDisplay. 

5. Tlie I IP SharedX extension creates windows on the re- 
ceiver's screen to match those on Ihe sender's screen. 

(i. As the windows are created and mapped, the receiver's 
X server generates a request to redraw the newly created 
windows. 

7. The application responds by redrawing the contents of all 
of its windows. X protocol drawing requests to redraw the 
windows are handled locally by the senders X server, as 
usual, but since the application is now shared, the protocol 
is effectively echoed to the receiver fj® in Fig. 1). Ihis is 
how the receiver is brought up to dale with the sender when 
the share is initiated. Incidentally, none of the resources 
(graphics contexts, fonts, and so on) exist on the receiver 
when the requests start flowing from Ihe shared application. 
Resources on the receiver are created when they are needed, 
thai Ls, at the point they are first used, and not when they 
are created by the shared application. As a result, the input 
from the application to the sender's X server and output 
from the sender's X server to the receiver's X server might 
look like the following streams: 



Input 

ClearWindowl winl | 
DrawLinel winl, gel. x. y I 
DrawLinel wm2. gc2. x, y ) 



Output 

ClearWindowl win la ) 
gcla ■ CreateGCI winla. 
DrawLinel winla, gcla, x, y ) 
gc2a = CreateGCI win2a, ... 
DrawLinel wm2a,x,y ) 



Fig. 3. Tin' III 1 SharedX ren-ivci service window. 
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Graphics Glossary 

The following ate some graphics terms that may be ot help in reading pans of this 
article that discuss graphics 

Color Map. A very high speed look-up table that maps the numbers stored in the 
frame buffer (video memory) to actual color values which are converted to analog 
voltages and sent to the monitor 

Frame Buffer. The video memory of a display device in which each element 
represents one picture element, or pixel The frame buffer is divided into two 
parts: onscreen memory (current visible image) and offscreen memory (graphics 
memory that is never visible). 

Graphic Context A set of attributes such as foreground and background colors, 
line styles, and fill patterns which are used by X clients to specify how the X 
server should render the drawing requests il receives 

Image Planes. The primary display memory on HP's display systems, used for 
rendering complex images. 

Offscreen Memory. A portion of the frame buffer that cannot be displayed on 
the monitor In all other respects, offscreen memory behaves the same as on- 
screen (visible) memory. Starbase and X use offscreen memory to hold character, 
cursor, pixmap, and scratch information for rapid transfers to onscreen memory 

Pixmap. A rectangle of image data maintained in offscreen memory when there 
is room, and in virtual memory when there is no room in offscreen memory 

Rendering. Any form of drawing operation, including text, line, and raster output 
Rendering may occur to onscreen memory, offscreen memory, or virtual memory. 

Visual Type. The color map capabilities of a given display Common visual types 
supported on HP displays include 1-bit static gray (or monochrome). 8-bit pseudo 
color (having 256 color map cells of RGB values), and 24-bit direct color (using 8 
bits each for red, green, and blue values). 



Note that these are only representations of the drawing 
commands sent from the application and I he sender's X 
server. The parameters win la and win2a correspond to the 
different windows created in step 5. The identifiers winla, 
gc2a, and so on represent resources on the sender's display 
which are mapped to resources winla, gc2a, and so forth on 
the receiver's display. 

Once the redraw step is finished, the share connection is 
established. From here on. the two displays are kept in 
synchronization by equivalent X protocol being sent to each 
server. 

Connector 

The HP SharedX connector (Fig. 2) is an X Window applica- 
tion that contains all the controls that enable users to set up 
and control application sharing. Using task analysis, we 
designed the HI' SharedX connector to match the user's task 
flow, thus providing intuitive controls to the complex opera- 
tion of sharing an application. Some of the usability features 
of the connector window include: 

• An address book (Fig. 4), accessible from the Receivers menu 
item in the connector window, to keep and organize common 
receivers and allow users to specify receivers by user name 
rather than machine name 

• A shared pointer (called a telepointer), available from the 
Windows menu item in Fig. 2, for users to point to areas of 
shared applications during collaboration 




Fig. 4. A window showing the address book. 



• Several cues, like changing a window title so that the user 
can keep track of the windows being shared, the users re- 
ceiving shared windows, and the receivers that can send 
input to the shared application 

• Various levels of dialog information (For example, when the 
user starts using HI' SharedX, a Normal dialog level is set 
giving the user complete status information about the qual- 
ity of the shared application. When the user sets the dialog 
level to Experienced, only critical errors are reported.) 

• Extensive online help information, including a troubleshoot- 
ing section for diagnosing and fixing problems when sharing 
applications. 

After the first release of IIP SharedX, we gathered informa- 
tion on the product to determine major usability issues. From 
this analysis three major issues emerged: 

• The need to annotate a shared window 

• The need for a "shared whiteboard" to assist in collaboration 

• The difficulty and security implications of the receiver's 
granting display access to the sender for shared applications. 

The first two usability issues are addressed by the HP 
SharedX Whiteboard (see "Whiteboard: A New Component 
of HP SharedX" on page 28). The third issue is addressed by 
the IIP SharedX receiver service (described below), a pro- 
gram diat is invoked on the prospective receiver's machine 
when sharing is attempted. 

Receiver Service 

When a sharing request is made to the connector via the 
Share button, the connector software first tries to invoke the 
receiver service program on the receiver's computer. The 
receiver service displays a dialog box on the receiver's dis- 
play (Fig. 3). The dialog box informs the user that the sender 
wants to share a window and asks for a yes or no response. 
If the user selects yes, the receiver service grants access to 
the receiver's display for sharing. 

The connector can get one of three responses from the re- 
ceiver service. The receiver can answer yes, in which case 
tlte connector will share the specified window. The receiver 
can answer no, in which case the connector will display a 
dialog box informing the sender that access permission was 
denied. Lastly, the receiver service may not be present, in 
which case the connector will attempt to share with the 
receiver's machine. 
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Fig. 5. Different application sharing architectures, (a) Centralized pseudoserver architecture, (b) Replicated architecture, (c) Sharing- 
library architecture, (d) Integrated architecture. 



i >nce III' SharedX has shared windows to the recover, tl 
tells the receiver service to remove display access from the 
sender. This prevents processes other than HP SharedX on 
the sender from making unauthorized connections to the 
receivers display. 

IIP SharedX Extensions 

The IIP SharedX extensions are low-level routines responsi- 
ble for intercepting data streams that flow in and out of the 
X server during a sharing session. These routines merge 
Input from multiple receivers and ensure that the receivers' 
displays are updated properly. 

Several groups of researchers have attempted application 
sharing in I he X window system environment .' 1 These imple- 
mentations can he classified into four different architectures, 
each with inherent strengths and weaknesses 4 (see Fig. 5). 
The main goal of sharing X applications is to ensure that the 
application and the basic X server don't have to change to 
work in a sharing environment. This requires some sort of 
interface mechanism between the application and the X 
server. 

By far the most popular architecture for window sharing in 
X is the centralized pseudoserver architecture (Fig. 5a). This 
architect lire places a process responsible for output multi- 
casting anil input merging between the shared applications 
iuid the X server.t This architecture is the most flexible, but 

I OutPM mulllMBling is the generation at multiple streams ot requests from a single stream 
Input merging invulves coalescing multiple streams ol events mm a single stream. 



suffers from performance problems, even by unshared appli- 
cations, because it places a process bet ween the application 
and the X server. 

Other application sharing systems have used a replicated 
architec ture for sharing windows (Fig. 5b). The replicated 
architecture runs a copy of the application for each receiver 
of the shared application and keeps these copies synchro- 
nized by sending identical input to each. Although this archi- 
tecture optimizes the image for each receiver of the shared 
application, it has been shown to be difficult to keep die 
instances of the application synchronized and nearly 
impossible to add users to an existing sharing session. 

The sharing-capable library (Fig. 5c) moves the output multi- 
casting and input merging found in the pseudoserver archi- 
tecture into the library of X functions (Xlib) linked into the 
application. By moving the sharing into an existing process 
and removing the pseudoserver process, performance is 
enhanced, but applications in such a system cannot be sure 
of sharability, either because they have not linked with this 
special library, or because they are running on a machine in 
the network that does not have the sharing-capable library. 

The integrated sharing arc hitec ture, which is used in HP 
SharedX, moves the output multicasting and input merging 
routines inside the sender's X server (Fig. 5d). This architec- 
ture ensures that all applications are sharing-capable, while 
eliminating the pseudoserver process. 

(continued un page 291 
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Whiteboard: A New Component of HP SharedX 



Whiteboard, a general-purpose image viewer and annotation X application, is a 
new addition to HP SharedX Whiteboard evolved from users' needs to annotate 
graphic images in shared applications Although it is impractical to annotate 
images in live X applications because ol limitations in the X Window System, 
Whiteboard allows users to share snapshots (portions! of their display and to 
annotate those snapshots. Not only is Whiteboard useful for adding annotation to 
computer images, it can also be used to create original images As an X applica- 
tion, Whiteboard is treated just like any other X application when it is shared in 
the HP SharedX environment 

Some of the other features that make Whiteboard convenient, powerful, and very 
functional when shared include 

• Annotation performed on an image can be erased without destroying the original 
image 

• Any region of the user's screen can be copied and pasted into the Whiteboard 
drawing area, even if the region contains areas of different X visual types. This 
ability to copy an arbitrary region containing multiple visual types is a new 
capability for X applications 

• When shared, Whiteboard knows when input is coming from the sender or receiver 
Thus, it can respond differently according to the source o( input This capability is 
used to ensure that receivers are restricted in what screen regions they can copy 
to the Whiteboard 

Fig. 1 shows a typical Whiteboard display 
Annotating Images 

The main feature that differentiates Whiteboard from other drawing applications 
is the concept of erasable and unerasable layers. Maintaining two layers allows 
users to erase image annotations without affecting the image being annotated. 

When an image is loaded into Whiteboard, it is in the unerasable layer. Annotation 
can be performed in the erasable layer and then erased without destroying the 
original image. This is analogous to drawing an image on a real-world whiteboard 
in indelible ink, annotating the image in erasable ink, and then erasing the board 
leaving the original image. This user model is convenient in collaborative situations 
where changing just: the image annotation is desired. For convenience. Whiteboard 
allows annotation to be hidden temporarily to reveal the unerasable image. 



Copying Multivisual Regions 

Copying a region from the screen is not as trivial as one might suspect To an X 
programmer, using the Xlib function xCopyArea to copy a root window region into 
an XPixmap buffer might seem like an obvious solution However, XCopyArea 
cannot handle cases in which the selected region includes areas of multiple visual 
types or visual types different from that of Whiteboard, the source and destination 
visual types must be the same to use XCopyArea In more recent X displays, a 
screen can simultaneously support multiple visual types differing in depth and 
types of color maps. Therefore, it is possible to have child windows of differing 
visual types in the window hierarchy, which is not an uncommon situation 

An algorithm was developed to convert all image data in the selected region to 
the destination visual type. This algorithm involves scanning Ihe selected region 
for all windows and parts of windows, coalescing those of the same visual types 
into subregions. then reading and converting each subregion to the corresponding 
subregion of the destination pixmap (paste buffer). If any subregion in the selected 
region matches the visual type of the buffer, a simple XCopyArea call is used to 
transfer the image information. Otherwise, the conversion algorithm uses functions 
m HP's Image Library to convert each subregion to the destination visual type 

If the X server on which Whiteboard is running supports deeper visual types than 
the default, Whiteboard keeps the paste buffer in the deepest visual type available, 
even though Whiteboard is running in the default (shallower) visual type. This 
technique maintains the buffer contents at the highest possible color fidelity, so 
that when a scaled paste is done, making the image larger, the resulting image 
does not contain pronounced dither patterns 

Recognizing the Source ot User Input 

Whiteboard is the lirst application that is able to detect the source of user input 
when the program is shared Whiteboard uses a feature of the HP SharedX exten- 
sions to the X server on the sender to examine events and determine the source of 
input. Based on whether the sender or receiver generates the input, Whiteboard 
performs a different operation when the Copy Region button is pressed. When the 
sender presses the Copy Region button, Whiteboard allows the user to select a 
region on the sender's screen to copy. However, for security reasons a receiver 
should not be able to copy the sender's whole display Instead, a Copy Region 
operation by the receiver confines the function to the Whiteboard drawing area. 




Rg. 1. A typical Whiteboard display the 
white arrow with the circle on ihe end ana ihe 
text illustrate a typical annotation The picture 
on the right, which shows a ioomed-in portion 
ol the mam image, is an example of copying 
and pasting a portion ot an image into Ihe 
Whiteboard 
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Ideally. Whiteboard should perform the copy from the display from which input is 
initiated Unfortunately, because Whiteboard does not have a direct connection to 
the receiver s display when the application is shared, no copying operations can be 
initiated from the receiver's screen Although the implemented Copy Region function 
does not present the most ideal solution, it does maintain complete functionality 
tor the sender while providing the receiver with a reasonable substitute for the 
copv operation 



The advantages of the HP SharedX extension architecture 
(integrated sharing architecture J include: 

• Any X application can be shared at any time 

• I'nshareri applications do not suffer a performance penalty 

• Sharing performance is optimized because state information 
about the X server is directly accessible to the sharing 
mechanism. (Other implementations require the sharing 
mechanism to query the X server stale over the network, 
slowing down the sharing process.) 

The main disadvantage of the HP SharedX architecture is the 
need to modify the X server, which requires access to the 
source r ode for the X server. Using the sharing-library ap- 
proach, an application can be linked with a sharing-capable 
Xlib and can then be run with any standard X server. 

Although these architectures for sharing applications differ, 
I he basics of sharing an application are the same for each 
(with the exception of (he replicated architecture). These 
basics include making instances of windows on receivers' 
displays, echoing the rendering requests of an application to 
each receiver, matching resources on the sender machine 
with those on the receiving machines, and merging input 
ev ents from the multiple X servers into a single stream and 
returning the information back to the application. The fol- 
lowing sections give a detailed look at how IIP SharedX 
deals with some of these issues in sharing applications. 

Limitations of HP SharedX 

Applications are displayed on HP workstations in one of two 
ways. They are either displayed via the X server using X 
protocol, or displayed directly using direct hardware access 
( l)HA). r ' DMA allows applications to bypass the X server to 
render graphics on the display. Since HP SharedX operates 
by retransmitting X protocol to the receiver's display, appli- 
cations based on X can be shared, while DIIA programs can- 
not be shared directly. The static images from DHA applica- 
tions can be shared by copying their windows into the 
Whiteboard application described on page 28. 

Programs lhal render through the DIIA mechanism include 
those that use the Starbase graphics pac kage or PEXt pro- 
gramming interface. However, the programming interface 
does not make the final determination of the rendering path. 
For example. Starbase programs can be run with a graphics 
driver that emits X protocol instead of using DHA. While 
there is usually some performance penalty for using these 
drivers, it does allow the application to be shared. 

Even if ;ui application is based on X, it may not share per- 
fectly. For example, the audio application of IIP MPower 
uses X protocol to display its control panel but interacts 
with the audio server to generate sound. Even though the 
control panel shares properly, when the receiver presses the 

t Pf X are 3D enhancements to the X pioiroil 





w 






Playing 
Sound 


Rendering 
Graphics 




To 
Receiver 



Audio 
Hardware 



Display 



HP SharedX 
Extension 



Audio 
Control 
Panel 



Fig. 6. \n UP SharedX Configuration in which output from a shared 
application is not echoed on the receiver. In this case the output is 
going to the audio server which knows nothing about the receiver. 

play button, the audio is played only on the sender's audio 
server (see Fig. 6), 

Another example of applications thai do not share perfectly 
are those applications that use X extensions. The X exten- 
sion is a mechanism for extending the capability of the X 
Window System. While the core X protocol is standard 
among all X servers, X extensions vary among X server im- 
plementations. HP SharedX only retransmits core X protocol, 
so applications that use X extensions will have limitations 
when shared. For example, if an application uses input de- 
vices other than the keyboard and mouse via the X input 
extension, tt the receiver will see a copy of the window but 
will not be able to interact with the application with these 
additional input devices. 

There are parts of the core X protocol that IIP SharedX can- 
not handle properly. One example is the X mechanism for 
cut ;uid paste. This mechanism uses a standard interprocess 
messaging system for transferring data from one X program 
to another. However, a receiver cannot cut and paste be- 
tween a shared application and one on the local machine. 
The two applications cannot communicate since they are 
not connected directly to the same X server. 

Establishing and Maintaining Connections 

When a share request is made to a receiver, IIP SharedX must 
first establish an X connection to the receiver's X server. It is 
over this connection that IIP SharedX will manage the 
shared windows, retransmit rendering requests, and get re- 
ceiver input The display connection is made using the X 
library (Xlib). 

Xlib is the client-side library of functions used by all X appli- 
cations. These functions create the protocol requests lhal 

tt The X input extension allows applications in irxeive mpui horn input devices such as graphics 
tablets, knot) boxes, hiilinn boxes, and so on 
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become the X protocol packets sent over the display con- 
nection to the X server to request creation of windows, 
drawing to those windows, and so on. Although the HP 
SharedX extension is in the sender's X server, it communi- 
cates with the receiver's X server using Xlib. This makes the 
sender's X server appear to the receiver's X server the same 
as any other X client. 

The I IP SharedX extension, however, has some requirements 
that are different from other X clients, so we made some 
changes to Xlib to accommodate these requirements. The 
First change we made to Xlib was to create a mechanism to 
recover from broken display connections. In X. programs 
that lose their connection to the X server normally print an 
error message and exit. For most X programs, their one con- 
nection to the X server is their lifeblood, and if it is broken, 
they may as well terminate. The sender's X server still has 
plenty to do if it loses a sharing connection, and thus it 
should definitely not terminate. Xlib calls a user-specified 
routine, XIOErrorHandler, when a display connection is broken. 
In HP SharedX's version of XIOErrorHandler, the routine cleans 
up tlata struct ures related to the broken display connection, 
sends a notification to the IIP SharedX user interface, and 
jumps back to a location inside the X server to conlinue 
processing. 

A similar problem occurs when the remote X server is not 
responding. This can happen for a variety of reasons such as 
that another program may have taken exclusive access to 
the X server, the network between the two computers may 
be very busy, or the receiver's X server may be busy han- 
dling requests from other clients. In any case, X programs 
wait indefinitely for requests to lie serviced before proceed- 
ing, which is not the desired behavior for the sender's X 
server. Therefore, IIP SharedX has added a timeout handler 
to Xlib that allows the sender's X server to recover from a 
nonresponsive receiver. After 30 seconds of waiting on a 
receiver's X server, HI' SharedX closes the display connec- 
tion and notifies the sender that the receiver's system is not 
responding. 

The final change we made to Xlib handles failure? to estab- 
lish an X (display) connection. Normally when a display 
connection fails, the program is not given a reason for the 
failure. A mechanism was added to extract the reason for 
display connection failure from Xlib and to return that infor- 
mation to the User interface. This information allows the 
user to diagnose problems more easily when attempting to 
share windows. 

Managing Shared Windows 

When users share an application, they usually have a clear 
idea of what constitutes the application and what set of win- 
dows should be shared. Most applications consist of a single 
program with a single connection to the X server. For these 
programs, it is easy for HP SharedX to share the right win- 
dows. However, an application can consist of more than one- 
program (e.g., IIP SoftBench), or a single program can dis- 
play several windows that should not be grouped together 
(e.g., the HP WE file manager can display multiple windows, 
each looking at a different directory). A user of the HP VUE 
file manager usually wants just one window to be shared, 
while a user of HP SoftBench may expect the debugger to be 
shared along with the static analyzer. 



From the point of view of the X server, windows partake of 
two relationships. One is a parent-child relationship, which 
defines a window tree with all windows as descendants of 
the root window. The other relationship is that in which 
each window is owned by a display connection. Each win- 
dow is uniquely identified by its window identifier, a 32-bit 
number in which seven of the bits are the same for windows 
owned by the same client. These seven bits are called the 
resource base. 

Applications typically consist of one or more top-level win- 
dows in which applications display information. Because 
windows are relatively inexpensive to create, they are used 
extensively inside an application's top-level window for 
everything from drawing areas to buttons and menus. 

When the user selects an application to share, HP SharedX 
mast select a group of windows that best represent the appli- 
cation to send to the receiver's display. IIP SharedX makes 
two assumptions: all top-level windows belonging to a single 
client connection (i.e., having the same resource base) belong 
to a single application, and all child windows of a shared top- 
level window should be shared with that top-level window. 

Using these assumptions, if the sender shares an HP VUE 
file manager window, HP SharedX will send to a receiver all 
file manager windows. Users have the option of selecting 
Share Alone from a mill-down menu, but they could easily 
forget which applications to do this for. However, HP 
SharedX can be configured to respond differently to the 
main Share button for differenl applications. For many appli- 
cations, HP SharedX is shipped preconfigured to share only 
the application's selected top-level window and its children. 

The other problem mentioned above, that of multiple pro- 
grams that should be shared together, has not been ad- 
dressed directly. While application developers could use the 
HP SharedX command line interface to tie their applications 
together, HP SharedX does not provide a simple mechanism 
for grouping windows from different programs. Typically, 
for t hese applications the user must manually share all the 
desired windows. 

Input Management 

HP SharedX allows both the sender and the receivers of a 
shared application to interact with an application. In X, 
application input consists of events from the user's input 
devices and queries that the application makes about these 
devices. For example, the application can query the position 
of t he mouse cursor, which, if the application is shared, has 
as many values as there are viewers of the application. 

Most application-sharing systems implement one of two 
input merging policies: floor passing or free-for-all. The floor- 
passing scheme allows one user at a time to input to the 
application, with the choice of the user who has the floor 
manually controlled by a moderator. The floor-passing 
scheme ensures (hat input is not mixed from multiple users, 
but it requires explicit user action to change the input floor. 
The free-for-all policy allows anyone to input without explicit 
action, but it is prone to intermixed input from multiple users. 

The HP SharedX input model, called dyiiumw floor passing, 
is a hybrid of these two methods. In (his scheme, only one 
user at a time can give input to the shared application. Thus, 
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user input does not become intermixed. However, input may- 
change among users dynamically without explicit action, but 
only after a specific period of inactivity by the current user 
giving input 

In addition to answering the problem of intermixed input, 
dynamic floor passing solves the problem of input queries. 
This method always returns the state of the user's input 
devices currently or most recently interacting with the 
application. 

Trie final challenge of handling input from multiple users is 
translating the actual input event that occurred on a receiver 
into an event that could have occurred on the sender. Trans- 
lating a window identifier is trivial because HP SharedX 
maintains a mapping of which receiver windows correspond 
to which sender windows. Translating the kcycodes in the 
event message is more difficult. 

The keycode specified in an event is an index into a mapping 
table of logical key symbols that can vary from one X server 
to another. For example, one server can map keycode 52 to 
the letter "a", while another server can map the same key- 
code to the letter "z". The keycode mapping table is loaded 
into the shared application when the display connection is 
made, but the mapping can be changed dynamically. 

When an event with a keycode is received by HP SharedX 
from a receiver, it is translated into a key symbol based on 
the current mapping for the receiver's X server. HP SharedX 
searches the sender's keyboard mapping to see if any key- 
code matches that same key symbol. If it does, the matching 
keycode is returned in an input event lo (he application. If 
no corresponding keycode on the sender's machine exists, 
(he key event is discarded sinc e no logical keycode can be 
sent to the application. 

The flow diagram in Fig. 7 shows the operation of the input 
merging routine, including dynamic floor passing control 
mid event-code translation. 

Allocating Display Resources and Rendering 

IIP SharedX uses a "lazy" allocation scheme for display re- 
sources such as colors, pixmaps. graphics contexts, and 
fonts. To minimize initial sharing time and (he impact on the 
receiving machine, display resources are allocated only when 
needed for a rendering request. For example, a shared appli- 
cation may allocate a large pixmap I hat is only displayed ful- 
some error condition. If dial error condition never occurs 
during the sharing session, it would be a waste of time 
and resources to make an instance of the pixmap on the 
receiver's machine. 

Once allocated, the display resource mapping is maintained 
so (hat future requests for tliat same display resource are 
satisfied without contacting (he receiving X server. For ex- 
ample, if an application requests a line be drawn lo a shared 
window, HP SharedX performs the following procedure: 

draw the line to the local display; 

lor each remote instance of the window 

begin 

if a remote instance of the graphic context has already 
been allocated, 
use that instance, 

else 

allocate a new remote graphic context and map it to 
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Fig. 7. Flowchart for Che III' SharedX [npul merging routine. 

the local graphic context; 
draw a line to the window instance with the graphic 
context instance; 
end; 

When the allocation of a display resource fails. HP SharedX 
uses several means to recover. In the case of pixmaps, HP 
SharedX c ontinues operation of the applic ation without the 
use of that image and notifies the user of this situation. In 
other cases, HP SharedX will substitute other display re- 
sources for (he ones il cannot allocate. The next two sections 
provide detailed examples of two display resources HP 
SharedX will gracefully degrade: colors and fonts. 

Managing Colors 

The management of display resources such as graphic 
Contexts and windows in HP SharedX is fairly straightfor- 
ward compared to the management of colors. The goal of 
displaying identic al images on all shared windows requires 
mapping colors from the sender's display lo the receiver's 
display and degrading the colors gracefully if the exact 
colors are unavailable. 
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The term pixel refers to the number that represents a color 
value. The pixel can be one of two types: read-only, which 
represents a color that does not change and can therefore 
be accessed by multiple programs simultaneously, or read/ 
write, which can be changed and is exclusively used by a 
single application. 

Pixels are converted to colors either by using the pixel as an 
index into a color map (a look-up table) or by Creating the 
pixel as a representation of the color itself. The interpreta- 
tion of the pixel is based on the visual type.t of which there 
are six in the X window system. Three of these allow X pro- 
grams to allocate read/write cells (grayscale, pseudo color, 
and direct color), while the other three provide a fixed set of 
colors (static gray, static color, and true color). 

To divide the six visual types another way, four of them 
(static gray, grayscale, static color, and pseudo color) use a 
single color map to map a pixel into a gray value or an RGB 
triplet ( Figs. 8a and 8b). These displays typically use bet ween 
one and eight planes, so their color maps typically store 
between 2 and 256 color values. Another visual type, (fired 
color, uses three color maps, one each for red. green, and 
blue. The pixel is decomposed into three indexes for look-up 
in the three color maps (see Fig. 8c). The last, true color, 
decomposes the pixel directly into red, green, and blue values 

l Color map capabilities Isee glossary on page 26) 



(see Fig. 8d). True color and direct color typically use either 
12 or 24 planes, yielding 4,096 or 16,777,216 colors. 

Our color mapping solution addresses two questions. Given 
the sender's and receiver's visual types, and the sizes of their 
color maps (number of different colors available): 
How are the available colors used to best advantage? 
How is color mapping maintained? 

Using the Best Colors Available. The key to color matching is 
always to have a color that is close enough if the exact color 
is unavailable. If the receiver's color display system is static, 
supporting only read-only colors, the solution is simple: map 
each sender color into the closest receiver color. For receiv- 
ers with dynamic color systems that support read/write col- 
ors, a color ramp is created. The color rani]) contains a set 
of colors evenly distributed I tin mghout the RGB color space, 
a three-dimensional space defined by axes of red, green, and 
blue values (see Fig. 9). The benefit of the ramp is that any 
color matches a ramp color within some maximum color 
difference in the color space. However, the maximum color 
difference may still be larger than is desirable, so the ramp 
is a fallback if an exact color match cannot be allocated. 

A color ramp array and the values for the receiver's color 
map are created when the display connection is made to the 
receiver for sharing. Fig. 10 shows an example of a color 
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Fig. 8. Fuur representations for the Color magenta, (a) The read-only gray level (statk gray or grayscale) equivalents for magenta, 
(b) Read-only static color or pseudo color representations, (c) Direct color representation of magenta. The pixel is split into indexes into 
the color map. (d) True color representation. The pixel value is split into parts, and each part is scaled to create the values for die different 
shades of red, green, and blue for magenta. 
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Fig. 9. A Uiree-dimensional representation of the color ramp for an 
8-bit color display with four shades of blue, four shades of red. and 
eight shades of green. 

ramp array that contains pointers to the color map on the 
receiver. The values in the color map are determined from 
the three-dimensional color ramp mentioned above. As each 
entry is allocated in the receiver's color map. the index to 
that entry is sent back to the sender and placed into the ramp 
array table, creating a table of indexes into the receiver's 
color map. 

The size of the color ramp depends on the size and type of 
the destination visual type. For grayscale visual types, a 
grayscale ramp of up to 1(5 values is allocated. For direct 
color visuals, up to lf> levels of red. green, and blue for a 
total of 4,096 distinct color values are allocated. In both of 
these visual types, 16 levels provide enough resolution to 
ensure a good color match without using excessive color 
map entries. The ramp used for eight-plane pseudo color 
consists of all combinations of four evenly spaced values of 
red, eight values of green, and four values of blue, for a total 
of 4 by 8 by 4 = 128 colors. The ramp takes up half of the 
available coitus in an eight -plane color map. 
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Fig. 10. The color ramp array containing indexes into the receiver's 
color map. Both of ilicse items an- created when I he connection 
between sender ami receiver is first established 




/ Blue 

Fig. 11. A two-dimensional representation of the color space used 
by the color-mat citing algorithm. 

Eight-plane pseudo color visual types are the most common 
and most difficult type to deal with since not enough colors 
exist to cover the color space adequately w ith a ramp. To 
compensate for large color errors, HP SharedX judiciously 
uses the remaining color cells available in addition to the 
ramp. For any given color, the following color-matching 
algorithm is used to map the sender's colors onto colors on 
the receiver 

1. If the X application on the sender allocated the color as 
read/write, then attempt to allocate a matching read/write 
color on the receiver. A read/write color is needed since the 
application may change the color of the allocated pixel at 
some later time and. to maintain color accuracy, the 
receiver's matching color must be changed as well. 

2. If the application allocated a read-only color or if the 
above allocation failed, find the closest color from the ramp 
or a previously allocated read-only color. If that color is 
close enough to the desired color, use it as the match. 

3. If the closest read-only color is not close enough, try to 
allocate a new read-only color. If this succeeds, add the 
color to the list of allocated read-only colors and return the 
new pixel as the match. 

4. If the read-only color could not be allocated, use the 
closest pixel from step 2 since it is the best available match. 
Notify the user that the colors do not match exactly. 

Fig. 1 1 shows a two-dimensional representation of the color 
space given in Fig. 9. Each circle encompasses colors that 
are close enough to a particular color ramp value (repre- 
sented by the point in the middle of each circle). Each of the 
points represents a read-only color that has already been 
allocated on the receiver's X server. 

The color-matching algorithm first checks to see if a color is 
close enough to an already allocated color. Point A in Fig. 1 1 
is close enough so another cell is not allocated (step 2 in 
algorithm). Thus, for point A. 2/3 red, 6/7 green, and some 
value for blue is used. 

Point B in Fig. 1 1 is not close enough to any allocated color, 
so a color is allocated and point B is added to the list of 
available colors (step 3 of the algorithm). If B cannot be 
allocated in the color map, the closest color is selected that 
has already been allocated, although technically it is not 
close enough (step 4 of algorit hm) 
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The difference between the desired color and the candidate 
color is measured as the sum of squares: 

diff = (desired_red - actual_red) 2 + 

(desired_green - actual_green) 2 + 
(desired_blue - actual_blue )- 

The color with the minimum difference is the closest color. A 
close enough threshold was determined empirically to opti- 
mize the accuracy of color images while minimizing the num- 
ber of receiver color cells used. Since images tend to have 
color themes (i.e., the colors are clustered in a few regions 
of t he color space), a fairly high degree of color accuracy 
can be Obtained without excessive demand for color cells. 

Private Color Maps. An X display has a default, shared color 
map that most applications use. If an application needs 
more colors than are available in the default color map, it 
can create and use a private color map over which it has 
complete control. When an application using a private color 
map has its window focused, that application's color map is 
installed (copied into the display hardware) by the X win- 
dow manager. On displays that support only one color map 
in hardware (most of the low-end displays), everything on 
the entire screen is displayed using the installed color map. 
When a private color map is installed, all applications using 
the default color map take on random colors. As soon as an 
application using the default color map gains the focus, the 
default color map is reinstalled, and the application with the 
private color map will have random colors. As the current 
color map switches back and forth from default to private, 
the user sees color flashing. The user typically prefers to 
display shared windows with the default color map to avoid 
this irritation. 

When a window is shared to receivers with display types 
that have read/write color maps, a color ramp is created on 
the receiver's X display. The ramp is created in the default 
color map to reduce the probability of color flashing. If the 
desired ramp cannot fit in the default color map, it is placed 
in a private color map. 

The system user interface is usually the first process to 
allocate pixels, and the pixels with the smallest indexes are 
allocated first. When a private color map is used, HP SharedX 
copies some of the lower pixel values from the default color 
map inlo the private color map. This way, when X switches 
between the two color maps, the colors used by the system 
user interface do not flash. The number of pixels copied is 
optimized to reduce color flashing while leaving color cells 
for later allocation. 

Keeping Track of Pixel Mapping. To minimize the number of 
times the color matching algorithm is executed, a mapping 
of previously matched pixels is maintained. Different map- 
ping methods are used depending on the range of possible 
sender color values. For small ranges (up to 256 different 
colors) a simple array is used, in which: 

receiver pixel = map |sender_pixel] 

When the sender is a 24-plane display, this approach would 
require 48 megabytes of memory, so a more memory-efficient 
mapping scheme is needed. Since the goal is to produce 
close colors for the receiver rather than exact color matches, 
resolution of the sender color is reduced before applying the 
color mapping. Red, green, and blue values of the color are 



reduced to four bits rather than eight bits for each plane, 
which results in 16 (2 4 ) levels of each. Thus, the total num- 
ber of possible color values is 4096 ( 16 3 ), a reasonable size 
for a mapping array. If color!) is a function that returns the 
RGB values of a pixel, and crunchl) is a function that converts 
an RGB triplet to a number in the range 0...4095 (four bits 
per pixel), then the mapping is as follows: 

receiver._pixel = map [crunch (color (sender.pixell)] 

The result of this mapping is that all colors close to a mapped 
color are mapped with that color. This method, called color- 
zone mapping, gives fast performance and adequate color 
matching, while keeping memory use fairly small. 

Matching Fonts 

The fonts in which applications display text can be specified 
by the user in the X Window System. From the set of fonts 
supported by the X server, the user selects a font that is 
aesthetically pleasing. Since there are no standard fonts in 
X, each X server can support a different set of fonts. 

To maintain consistency between the sender and receiver of 
a shared application, it is important that text be displayed in 
a similar font on the receiver's display. HP SharedX employs 
a font matching algorithm to ensure a close font match. 

Fonts in X have both a name and characteristics. A font can 
be loaded by specifying either its name or its characteristics 
using the X Logical Font Description (XLFD) format. HP 
SharedX first tries to match the font by name since it is un- 
likely that fonts with the same name differ. If the font with 
the same name is unavailable on the receiver's X server, 
fonts are matched by I heir charact eristics. 

The XLFD description defines 13 characteristics of a font 
such as its size, character set. weight, slant, and style. When 
matching fonts for the purpose of sharing an application, 
some of these characteristic s are more important than others 
in choosing the font with the closest characteristics. 

HP SharedX obtains a list of all XLFD type fonts from the 
receiver's X server at display connection time. When a fonl 
match is needed, the source font's characteristics are com- 
pared to those available on the receiver's X server. A 
weighted sum of differences of the characteristics is calcu- 
lated and the font with the minimum difference is considered 
the closest match. 

The weighting of characteristics was determined through a 
combination of intuition and observation. With the excep- 
tion of character set. discussed below, it seems clear that 
size is the most important criterion, with width taking prece- 
dence over height. This is partly because many X applica- 
tions write text in two different ways. One way is to pass a 
whole string of characters to the serv er and let it determine 
the location of each character based on its knowledge of the 
font. The other way is for the program to control the spacing 
and send one character at a time to the X server. The pro- 
gram must then know about the character widths for the 
font in use. In this method, the program has no knowledge 
that the receiver may be using a different font with different 
spacings, and characters may overlap or be widely spaced 
for their size. If the first method is used, the receiver's X 
server will correctly space the characters for the font in use. 
but the positions of characters within the window will be 
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incorrect. If both methods are used, as they are in terminal 
emulaiors. the receiver is faced with a messy mixture of 
incorrect spacings and characters in incorrect positions. 

Another important factor with respect to spacing is whether 
a font is proportional or monospaced. Proportional fonts use 
different widths for different characters, while a mono- 
spaced font uses the same space for all characters. In most 
cases, it is better to match a monospaced font to another 
nionos|»red font, even if they are of slightly different size, 
than to match it with a proportional font of the same size. 
Likewise, matching a proportional font with another propor- 
tional font tends to give the best appearance, and if the type- 
faces are similar, the chance is high that specific character 
widths will be similar. 

The issue of character sets is an easy one for an English 
speaking person to ignore. Almost all fonts have identical 
characters in the range of characters most often used (the 
ASCII characters) numbered 32 to 127. The differences lie 
mainly in the upper range, the characters numbered 128 to 
255 and beyond. This is where characters with special 
accents, used in most European languages, are found. If 
ac cented characters are used, the difference in character 
sets is very important . 

This issue becomes more important when character sets for 
pictograms or entirely different alphabets are used. If the 
character set does not match, the receiver is given meaning- 
less garbage. But what constitutes a match? Does the name 
of the character set have to match exactly, or are there more 
or less equivalent character sets that have different names? 
These issues have not been addressed in the current font 
matching algorithm. Eor HP SharedX to work acceptably 
with these types of characters, it is best to have the same 
font on sender and receiver machines. 

Performance 

The performance of HP SharedX depends on the character- 
istics of the network connection, the performance of the 
workstations involved, the application being shared, and the 
operations performed with the application. There are three 
networking factors thai affect performance: network speed 
or bandwidth, line delays, and network load. Increased load 
is roughly equivalent to dec reased bandwidth. Performance 
increases directly with network bandwidth, up to a limit of 
about 500 kbits/s for an unloaded network. Beyond thai, 
other factors limit performance. Line delays are of greater 
importance when sharing over a wide area network (WAN ). 
Screen update limes increase proportionally to line delays. 

Given a network with reasonable bandwidth, IIP SharedX 
performance will be greatly affected by the performance of 
the computers involved in the sharing, especially the send- 
ing machine. When users have a choice of who sends and 
who receives, the person with I he fast er machine should be 
t he sender. 

Applications vary widely in how they make use of X. For 
example, an application receives an expose event from the 
X server, indicating thai some portion of a window hasjusl 
become visible and therefore needs redrawing. Some appli- 
cations redraw the entire window, while others are more 
efficient and only repaint the portion that is exposed. A 
word processing application may update the entire window 



every time the user types a letter. While this scheme works 
acceptably when not sharing, this application is nearly 
unusable when shared. 

If application windows can be resized, the sender can im- 
prove performance by making windows smaller. Also, users 
often come to recognize slow operations. If resizing can l>e 
done before starting the sharing session, there will be less 
demand on the network. If the application is still too slow 
w hen shared, the sender can take snajishots of it with the 
Whiteboard and share the Whiteboard. 

Lazy allocation of resources in HP SharedX affects perfor- 
mance in some interesting ways. For example, the White- 
board uses two large pixmaps for the drawing area one for 
the erasable layer and one for the unerasable layer. The 
erasable pixmap is allocated immediately when the White- 
board is shared. The other, however, is not used until the 
user does an erase operation. The user may be typing some 
text into the drawing and then hit the backspace key. At thai 
point, the Whiteboard and all other X programs on the send- 
er's display "freeze" while the unerasable pixmap is created 
on the receiver's X server. 

When more than one receiver is involved in a sharing ses- 
sion, the method of connection becomes important, if there 
is one receiver, and the parlies involved want to add a sec- 
ond, either the sender or the receiver can share to the new- 
person. The first receiver sharing to the second receiver is 
called daisychaining. The sender sharing to more than one 
receiver is called fanning out. With the right combination of 
daisychaining and fanning out, an application can be shared 
to a large number of people. 

Determining an optimal configuration for one-to-many 
sharing is more complex when the computers vary in perfor- 
mance or when the network links between the parties vary. 
Some general rules for optimizing performance are: 

• The fastest machines should bfi daisychaining. and slow 
machines should all be leaves in the sharing tree. 

• When some of the receivers are connected by a LAN, while 
others can only be reached over a WAN, the number of WAN 
connections should be minimized. 

For example, if a sender in Colorado is sharing a window to 
live receivers in New York and three receivers in California, 
it is most efficient for the sender to share the window to the 
fastest receiver in New York and the fastest receiver in 
California and have those receivers share to others on the 
same local network. 

Conclusions 

The implementation of HP SharedX presented several prob- 
lems. First, and foremost, since Ihis type of technology is 
new, no foundation of past experience was available to build 
Upon, especially when it came to designing the HP SharedX 
user interface. The user interfac e design Challenges were 
solved by applying human factors design techniques, includ- 
ing user task analysis and human factors testing. The HP 
SharedX extension presented a totally different challenge, 
including handling input from multiple sources in a sane 
IttKiner and applying X protocol customized for a machine 
of one type and mapping il to machines of very different 
lypes. The IIP SharedX extension challenges were met by 
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understanding the nature of the X window system and grace- 
fully degrading the display image when receiver display re- 
sources do not match those of the sender's display. Although 
there are no perfect answers to any of these challenges, the 
value of IIP SharedX far outweighs its limitations. 
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Imaging Services in a Multimedia 
Environment 



Image manipulation tools, compression and decompression functions, 
picture quality adjustment techniques, and support for industry standards 
are some of the features included in the HP Image Library. 

by Andrew Munro and Ahmad H. Shekarabi 



On UNrX*-system-based computers words are the tradi- 
tional means of communication whether the user is creating 
a business report or presentation, writing a functional speci- 
fication, or sending electronic mail. While the topic might 
benefit from some visual content, the user usually finds it 
easier I o just use words. 

Unfortunately, words may not be enough. The user could be 
describing CAD graphics that remote colleagues need to see. 
Perhaps, the user is an insurance adjuster who is sending a 
report to the home office that describes photographs of dam- 
aged property. Another user may be describing the appear- 
ance of a c omputer screen that a customer support engineer 
needs to see. 

Without imaging capabilities on die computer, the aser may 
resort to noncomputer means, such as the postal service. In 
send images. 

This article describes the major parts of the HP imaging 
solution, how it meets the characteristics required of an 
imaging system, and its application to IIP MPower. 

Image Files 

Image files contain computer graphic s and digital records of 
physical objects, such as photographs, pages from books, 
and faxes. The images of these objects are represented as 
collections of bits called pixels. 

Image data comes from several sources including screen 
captures, video frames, and external devices such as scan- 
ners, video recorders, or fax machines. Once the image data 
is collected in a file it can be displayed, modified and saved, 
or printed. 

The dala in image files is stored in different formats. These 
image formats are more commonly called image types. The 
most popular image file format is called lagged image file 
format, or TIFF. The following are some of types of images 
stored in TIFF files. These image types are listed in order of 
image quality — f ro1 " a simple monochrome to the highest- 
quality color: 

Bitonal. Bitonal images contain pixels with two levels — 
black and white — but they can be displayed using any two 
colore. Eac h pixel lakes one bit. Bitonal images are fre- 
quently referred to as monochrome images. They often con- 
tain text, such as a page of a fax. 

Grayscale. Grayscale images contain pixels thai identify 
levels of gray, from black to white. Grayscale images are 



sometimes also referred to as monochrome images. They 
are often used for images of scanned photographs. 

• Palette. Palette images contain pixels tiiat index into a color 
map containing the red. green, and blue values for the pixel. 
The color map has three contiguous sections: red, green, 
and blue, each with 256 16-bit entries. The color of a pixel is 
determined by using the pixel value as an index into each of 
the red, green, and blue sections to obtain die desired color. 
This is the lowest-quality color image and is also called a 
pseudo color image, a type c ommonly used for computer- 
generated images. 

• RGB. An RGB image contains pixels with three samples: 
red, green, and blue. Each sample identifies a level of thai 
primary color. This is a good-quality color image type that is 
typically used for photographs. RGB format provides better 
picture quality than the palette formal because RGB pro- 
vides 2-' 1 color variations for images, whereas I he palette 
provides 2 s color variations for images. 

• YCbCr. A YC'bCr image contains pixels with three samples 
in the order Y, Cb, Cr. (YCbCr images are often incorrectly 
termed YUV images.) The Y sample is called the luminance 
sample; it represents the gray level of each pixel. Cb and Cr 
are called die chrominance samples. Together with Y, they 
represent the color of each pixel. An RGB image can have 
the same lugh quality as a Y( 'bCr image, but a YCbCr image 
often requires less disk space. 

These image types are supported by die image libraries 
described in this article. 

I sing linage Files 

In trying to provide a software alternative that makes using 
images as easy as using text , an application developer is 
usually faced with the following issues from potential 
customers. 

• I don't have enough disk space to store images. 

• If I compress my images, won't diey become slow to display? 

• How can I clearly display photographs when the screen's 
resolution is only 5% of the photograph's resolution? 

• Aren't there too many computer formats of image files to 
deal with? 

Because of these issues, Hewlett-Packard took a compre- 
hensive look at the imaging requirements of end users and 
application programmers. From this investigation, the image 
library project team determined that an imaging solution 
with the following characteristic s would be needed lo fulfill 
the needs of both applic ation developers and end users: 
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Fig. 1. The four types of tillages the HI" Image Library ran read, 
write, and display. 

Support for industry-standard image file formats 
Minimum disk space requirements for storing images 
Fast, high-quality display of compressed and uncompressed 
images 

Basic image manipulation, such as rotating and cropping 
Extensibility to allow programmers to add custom image 
functions and custom image file formats. 

The solution we created to help fulfill these needs has three 
parts: libraries of image functions built on the X Window 
System, end-user tools built on these libraries, and an image 
developer's kit with an extensible application interface. 

HP Image Libraries 

To make imaging functionality a standard capability on HP 
9000 Series 700 workstations and Series 800 multiuser sys- 
tems, the image team decided to create two libraries and 
build them into the standard run-time environment. These 
two libraries, the imaye library and the extensible file sup- 
port library, contain high-level functions thai C programs 
can use to access and manipulate images. These I wo libraries 
are collectively called the HP Image Library. With the HP Im- 
age Library functions, applications can read and write im- 
ages that exist in four forms: 

A file image. This is an image in a single or mullipage file 
(e.g., a file containing the image of a fax cover page plus 
one or more other fax pages). 

A client image. This is an image in memory that is created 
and managed by a client application separately from the HP 
Image Library functions. 

An internal image. This is an image in memory that is 
created and managed by the HP Image Library functions. 
X Drawable. An X window image such as an HP terminal 
window or an X pixmap such as an icon symbol. 

Fig. 1 summarizes the relationship between these four forms 
of images and the HP Image Library. 

While the image library functions support TIFF image files, 
the extensible file support library addresses support of non- 
TIFF image files. The extensible file support functions oper- 
ate on image files in an object-oriented approach, indepen- 
dently of the file type. Therefore, if the programmer defines 
a new type of image file, the existing client programs 
continue to work on the image file without modification. 
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Fig. 2. The image library and extensible file support library in the 
client/server architect ure. 

All hough the extensible file support library also supports 
TIFF, that support is not as extensive as the image library 
support of TIFF. The extensible file support or TIFF files 
enables applications to treat TIFF files as merely another 
image file. 

The HP Image library runs on the HP-UX* operating system 
and uses the X Window System to display images (see Fig. 2). 
Because the image ftinctionality is layered on standard X, 
the user gains all of the client/server advantages of X. 

Using Pipes to Access Images 

To simplify the programming task, the image team designed 
i he image library and the extensible file support functions 
around the concept of an image pipe. An image pipe is a 
series of calls to functions, beginning with a producer (a 
function that reads an image from a source such as an image 
file) and ending with a consumer (a function that writes an 
image to a destination such as a display). Fig. 3 shows the 
steps in a sample image pipe. 

While only one producer and usually only one consumer 
function are allowed per pipe, the pipe can also contain 
functions that manipulate the image. These filter functions 
perform operations such as decompressing, scaling, rotating, 
or converting the image. 
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Fig. 3. The steps in an image pipeline. 
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A producer can access any form of image I.Xwd. file image, 
client image, or internal image). Filters operate on the image 
data supplied by the producer. The consumer receives the 
filtered image and writes it to the display, a file, or an internal 
or client image. 

When the pipe is executed, it processes the image in hori- 
zontal slices, which are called strips. Processing strips re- 
quires smaller buffers between filters and less memory than 
processing an entire image. Because processing strips can 
be located in cache memory, image processing performance 
benefits. For complex image processing, images begin to 
appear quickly because there is no need to wait for the 
entire image to be processed before displaying it- 
Industry Standard File Types 

Since there are several sources for images (e.g., scanners, 
PCs, fax machines. LAN, and so on) multiple types of image 
file formats have emerged. 

To enable applications to handle these different file types, 
the HP Image Library provides reading and writing support 
for I lie image file types listed in Table L 

The following are definitions for file types not defined earlier. 
LZW. Lempel-Ziv and Welch compression formal (described 
below) 

Xwd. X window (an image created by storing the contents 

of an X window in a file) 

GIF. A c ommon format for palette images 

JPEG. Joint ('holographic Expert Group compression, a 

lossy compression format 

JFIF. JPEG compression that does not conform to TIFF 
specifications. 

Compression and Decompression 

Image compression is a process of storing an image in a way 

that uses less disk space than is used by the uncompressed 

image. In developing the compression and decompression 

routines for the IIP Image Library, the image team had to 

account for three fac tors: 

The quality of t he displayed image 

The speed of decompressing and displaying the image 

The amount of compression required. 

The quality of the displayed image partly depends on whether 
lossless or lossy compression is used. Lossless compression 
involves techniques that allow the image to be perfectly re- 
ronstnicted. This method of compression stores the infor- 
mation about the repetitive patterns of pixels rather than 
storing every pixel. For example, for a sequence of 25 pixels 
each having a value of 92, lossless compression could store 
two items: one pixel of value 92, and the information that 
this pixel repeats 25 times. 

Lossy compression is a method that uses different techniques 
to achieve even lower storage 1 requirements than lossless 
compression. Lossy compression is recommended for photo- 
graphic images. For the HP Image Library, lossy compression 
is based on discrete cosine transform (DCT) techniques. 
These are numerical techniques that transform complex color 
or grayscale Information into less complicated information. 
Although the original color or grayscale values are lost, the 
image normally appears identical when it is decompressed 
and displayed. 



Table I 

File Types Supported by the HP Image Library 

File Type Reads Writes Typical File Contents Version 

TIFF Types 5.0, 6.0 

Bitonal Yes Yes Line art. text 

Grayscale- Yes Yes1 Black and while 

photos 

Palette Yes Yes Color photos and X 

screen dumps 

RGB Yes Yes High-quality color 

photos 

YCbCr Yes Yes High-quality color 

photos 

Compressed TIFF Types 5.0, 6.0 

PackBits Yes Yes Compression for the 

bitonal images 

LZW Yes Yes General-purpose 

compression 

CCITT Yes Yes Common fax images 

Group 9 

CCITT Yes Yes Common fax images 

Group 4 

JPEG Yes Yes High-quality color 

photos 

X Image Types XI 1 

Xwd Yes No Pixmap image from 

Xwd (Z format) 

Xbm Yes No Bitonal X bitmap 

images 

Xpm Yes Yes Color ASCII 

X pixmap images 

JFIF Yes Yes Color photos and 8-R8 

continuous tone 
images 

GIF Yes No Xv/Xgif network im- 87a 

ages, dialup services 

Starbase Yes No HP Starbase pixmap I 
Pixmap images 

t Writing grayscale images is supported only in 8- bit format 

To address user concents about disk space, the HP Image 
Library supports a full range of compression and decom- 
pression methods. Application programs can access the 
compression and decompression methods listed in Table II 
through the IIP Image Library. 

Except for JPEG and JFIF compression, all compression 
methods are lossless. Although JPEG is lossy, that loss is 
normally iinnoticcahlc unless the image is compressed by 
more than a factor of 20 times. 

Typically, lossless compression methods reduce the storage 
requirements to 50% of the original disk space. However, by 
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Table II 

Compression and Decompression Methods Provided 
in the HP Image Library 

Compression and Image Types 

Decompression Method 

JPEG Grayscale, RGB, and YCbCr 

.IFIF YCbCr 

Group 3 Bitonal 

CCITT Group 3 Bitonal 

CCITT Group 4 Bitonal 



LZW 
PackBits 



Bitonal, grayscale, palette, 
RGB, and YCbCr 

Grayscale, palette, bitonal 



using the lossy JPEG compression technique, a typical com- 
pression reduces the storage needed to 5% of the original disk 
space. However, the image library still displays the photo- 
graph with high-quality resolution and no noticeable change 
in display time. 

All the compression methods provide fast display and high- 
quality image appearance. For JPEG, the fastest display im- 
plementation is provided in the version of the IIP Image 
Library supplied with HP MPower. With JPEG, the program- 
mer can choose the amount of compression by t rading off 
the amount of compression with the image quality desired. 

Before compressing a color image file with JPEG, the appli- 
cation can save addit ional space by first converting the file 
to YCbCr format and subsampling it. Subsampling is a tech- 
nique that reduces the color information to be compressed, 
without noticeable change in the image quality. Subsampling 
is really a form of compression, because it stores fewer pixels 
than exist in the image. Because the human eye perceives 
degrees of brightness with much higher resolution than ex- 
act shades of color, only a fraction of the chrominance sam- 
ples are stored. After subsampling, the subsampled bits can 
be replicated before displaying the image. The replication 
process is called upsampling. The upsampled image looks 
identical to the original image. 

If the application needs to send files to a fax machine, it can 
use (he CdTT Group 3 and Group 4 compression methods. 
However, most fax machines support only Group 3 format. 
The HP Image Library can convert any type of image it sup- 
ports to any other type it supports. Therefore, a photographic 
image in RGB format can be converted to CCITT Group 3 
formal so that the file can be sent to a fax machine. 

To compress images, end users must experiment with com- 
pression methods on various types of images. The following 
general guidelines are helpful in determining which compres- 
sion method to use for reducing the storage requirements of 
images: 

For photographic images when some of the image detail 
can be sacrificed, choose JPEG (choosing the desired 
compression amount) or .IFIF 

For Xwd (X window) screen dumps, or other computer- 
generated images, use LZW. 

For image files being sent to a fax machine, use CCITT 
Group 3. 



i For fax files to be stored or sent to HP MPower systems, 
use either CCITT Group 4 (if the content is mostly white 
space, such as text) or either Group 3 or CCITT Group 3 
(if the content is highly detailed). 

i For images being ported to various non-HP-UX systems, 
choose PackBits. 

Display Quality 

Because the resolution of an image on paper can be 20 to 
100 times higher than that of the computer screen, end users 
are concerned about image display quality. To optimize the 
appearance of displayed images, the image team included 
the following capabilities in the IIP Image Library: 

1 Simultaneous display of different color images by sharing a 
common color palette for 8-plane displays 

• Gamma adjustment of colors, such as changing the 
brightness of ait image 

Programmable choices for the type of dithering technique 
used 

Automatic dithering of images on S-plane displays and 
remapping of pixel tones 

Automatic conversion of color images to grayscale format 
on monochrome displays 

Programmable conversion of bitonal images to display as 
grayscale images. 

Dithering 

Dithering is a technique that trades screen resolution for 
more colors or gray levels. While the resulting image may be 
more grainy than the undithered version, the contrast be- 
tween the greater range of colors or gray levels provides 
improved appearance. Dithering is accomplished by modu- 
lating the color values between two adjacent color tones. 
From a moderate distance, the human eye automatically 
blends these regions of color together and perceives the 
average intensity. 

Two options are available in the IIP Image Library for dither- 
ing: error-diffusion dithering, using what is called the Floyd- 
Steinberg method, and area-based dithering. Compared to 
error-diffusion dithering, area-based dithering provides a 
more matted appearance in the image (see Fig. 4a on page 
42). However, if speed is the primary concent, an image can 
be displayed faster by using area-based dithering. 

For area-based dithering the HP Image Library performs the 
following two steps: 

L In one area at a time, it applies an S-by-8 array of positive 
and negative values to the color or grayscale values. This 
step preserves the average c olor or grayscale level in the 
area, because the sum of the values in the array is always 
zero. 

In a simplified example, this step might subtract 20 from the 
value of half the pixels and add 20 to the value of the other 
half of the pixels. Thus, the average value of the pixels in the 
area remains the same. 

2. The values from step 1 are reduced to a number of values 
that the screen can display. For example, in a grayscale image 
values 1 through 256 need to become values 1 through 32 for 
a monochrome screen. In this example, each v alue is divided 
by 8 (256732). Pixels of gray level 1 through 8 become value 
L, values 9 through 16 become 2, and so on. 
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In error-diffusion dithering, the HP Image Library changes the 
values of pixels one at a time rather than working on areas 
of pixels. After assigning a dithered value to one pixel, error 
diffusion records what the difference was in that pixel's 
value. Thai difference is then added to the next pixel's value 
before it receives its dithered value. 

For instance, suppose there are two neighboring pixels with 
values of 90 and 140. If the pixel with the value 90 receives a 
dithered value of 100. the difference is 10. So. 10 is added to 
the next pixel's value of 140, making a pixel of value 150 be- 
fore it receives its dithered value. Perhaps the 150 is dithered 
to 170. making the current difference 20. So, 20 is added to 
the next pixel, and the process repeats. 

Error diffusion is the dithering method used by the HP 
MPower Image View tool.T whereas area-based dithering is 
the default dithering method. 

Before displaying an image, the HP Image Library checks the 
characteristics of Ihe display device to determine if dithering 
is necessary. The HP Image Library automatically dithers the 
image when displaying an RGB or YCbCr image on a pseudo 
color display device or displaying a grayscale image on a 
bitonal device. 

For RGB images on a pseudo color device, the HP Image 
Library' uses area-based dithering. For grayscale images on a 
bitonal device, the library uses error diffusion. When a gray- 
scale image is displayed on a bitonal device, the HP Image 
Library dithers it to a bitonal image. 

By default, the IIP Image Library chooses the dithering 
method by using the following criteria: 

• If I he screen is a pseudo color (palette) image, area-based 
dithering is used. The image is First converted to RGB and 
then to palette. 

• If the screen is monochrome (bitonal ), error diffusion is 
used. The image is first converted to grayscale, then to 
bitonal. 

Image Conversion for Space and Readability 

For reasons such as saving space and improving the read- 
ability of text-oriented images, an application can convert 
images from one image type to any other image type. 

Space and Color Images. The high quality of a 24-bit RGB im- 
age is only visible on a 24-plane system. When displayed on 
an 8-planc display system, an RGB image is automatically 
converted to palette. However, an uncompressed 24-bit RGB 
image occupies more space than it would as a palette image. 

To save space on 8-plane display systems, the application can 
convert the 24-bit RGB images to palette or YCbCr format. 
YCbCr format is preferable if JPEG c ompression is also used. 
Beyond Ihe additional compression possible, the image 
space required can also be reduced through the subsampling 
technique. 

Space and Text Images. Concerning monochrome images, the 
programmer can save space by converting grayscale images 
of text In bitonal images. A grayscale image requires eight 
limes the space required by a bitonal image. 

t ImageView ll a tool lor displaying, manipulating, saving, and printing images ol dilferent 
image types 



HP Image Library Scaling Functions 

The HP Image Library scaling capability performs three types of scaling according 
to which option is used: scale to gray, area-sample scaling, and simple scaling In 
each case, the scaling algorithm accounts for the type of image involved, whether 
any image type conversion is needed, and whether the program is requesting that 
the mage be scaled up or down. 

Simple Scaling 

Simple scaling gives the fastest scaling performance out the lowest image quality 
This method uses pixel replication if the image is enlarged and pixel decimation if 
the image is being reduced No image conversion is performed 

Area-Sample Scaling 

Area-sample scaling gives the highest-quality scaling results. This method only 
applies to scaling an image down in the current release of the HP Image Library In 
scaling the image down, sample scaling uses area sampling techniques based on 
the image type; 

• For a color palette image, the image is first converted to an RGB image The RGB 
image is scaled by area sampling. 

• For bitonal images, the image is temporarily converted to an averaged grayscale 
type and then the image's pixels are set to on or off. based on a threshold value 
set by the application (High-threshold values darken the image and low-threshold 
values lighten it I The resulting grayscale image is then scaled by area sampling. 

Bitonal-to-Gray Scaling 

Bitonal-to-gray scaling applies only when scaling down bitonal images. It converts 
bitonal images to grayscale and uses area-sampling techniques to scale the image 
down. To convert a bitonal image to a grayscale image. Ihe HP Image Library assigns 
each black or white pixel a gray level between 0 and 255 



While a scanned photographic image should be a grayscale 
image to retain the different levels of gray, a scanned text- 
oriented document or other text image can be bitonal and 
still be read from the sc reen by users. 

Readability and Text Images. When a grayscale image of text is 
stored as bitonal. it can be convened back to grayscale if it 
was scaled down for display. The result is text that is easier 
to read. Thus, the image can be stored as a bilottal image, 
using less space, and displayed as a grayscale image. 

Image Manipulation 

To manipulate images, the HP Image Library includes a num- 
ber of functions for scaling, rotating, mirroring, cropping, 
and changing image colors. 

Scaling Images. The sc aling function maps one image into an 
image of a different resolution. It allows the application to 
account for the differences in resolution between Ihe dis- 
play screen and the image captured by devices such as scan- 
ners. It also provides a mechanism to resize images to differ- 
ent window resolutions (see "HP Image Library Scaling 
Functions." above). 

An application can scale an image up or down. For example, 
scanners are typically :$()() dpi and display monitors are only 
90 dpi. Therefore, images scanned at LOO dpi or higher 
resolution must be scaled down to the screen resolution. 

The sealing function includes options for faster scaling or 
high-quality scaling. Faster scaling replicates or removes 
pixels, depending on whether Ihe image is being scaled up 
or clown. High-quality scaling converts bitonal images to 
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Fig. 4. A comparison between (a) area-based dithering and (b) error-diffusion dithering. 



grayscale or scales color images by area sampling. Area 
sampling replicates pixels based on the average color values 
of an area of pixels, producing a clearer image. 

Rotating and Mirroring Images. The rotation function rotates 
an image at integer multiples of 90 degrees. The rotation can 
l>e clockwise or counterclockwise. If the image is rotated by 
90 or 270 degrees, the width and height of the image are 
reversed. Otherwise, the image retains the same dimensions 
as before rotation. The mirroring function mirrors the image 
about the x or y axis. 

Cropping Images. The cropping function extracts a rectangu- 
lar section of an image, creating a cropped image that is 
either the same size or smaller than the original image. An 
application might combine the scale and crop functions to 
implement features such as paiming and zooming. 

Changing Image Colors. The color mapping function changes 
the image colors by mapping the color values of the image 
pixels into different color values. This funciion can be used 
by applications to change the colors, brightness, or contrast 
of the image. 



Custom File Types and Custom Functions 

To allow programmers to extend the IIP Image Library, func- 
tions are included for defining new types of files and creating 
custom functions. 

Custom File Types. For unsupported types of image files, trie 
programmer can extend the extensible file support library. 
The programmer defines a new type of file using an extensi- 
ble file support funciion and i hen rebuilds the extensible file 
support library. 

Thus, if an existing application accesses files tlirough the 
extensible file support library, the newly defined file type 
can be accessed as just another extensible file support file. 
This object-oriented approach allows the programmer to 
create routines Without worrying about what type of file is 
being manipulated. 

Custom Image Functions. For capabilities not available in the 
HP Image Library, the application can define a new function. 
An applical ion-defined function (or custom funciion) can be 
a producer, a filter, or a consumer function. 
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Fig. 5. An HI' ImafipViuw screen. 



Application-defined producers and consumers might be used 
to read or write to an image-capable device. The application- 
defined producer outputs a pipe image, ideally in strips, that 
may have :m input image type tiiat is unknown to the image 
library but known to the application-defined consumer. The 
application-defined consumer can be defined to accept a 
standard or nonstandard input image type that is unknown 
to the MP Image Library. 

An application-defined filter can be created to operate on a 
client image that is not in a format supported by the MP Im- 
age Library. For example, the client image can be created to 
Support a color image in CMYK (cyan, magenta, yellow, and 
blac k) format. While standard IIP Image Library functions 
can read and write this client image, operations to manipu- 
late the image require an application-defined function. 

End-User Image Tools 

Based on the image and extensible file support libraries, 
end-user tools have been c reated by the image team and 
several other MP teams. For example, the HP online help 
facility, and the MP MPower components fax. DeskScan/UX, 
Whiteboard, ImageView, and HP SharedPrint use these 
libraries lor image display and manipulation. 

A central part of the HP MPower image display is Image- 
View, an ' iSF/Motif-based image display application (see 
Fig. 5). A basic version of this application is built into the 
standard run-time applications on MP 9000 Series 7(1(1 and 
800 systems. 



As a client application of the image libraries. ImageView 
displays all the file types supported by the extensible file 
support library- The user displays an image by double- 
clicking on a file icon in HP \T"E. The user can then zoom 
in on arbitrary areas of specific interest and resize images 
by dragging a comer of the window. 

In the HP MPower version of ImageView, users can also 
compress an image file, print images, adjust contrast, bright- 
ness, and orientation, and save those changes. Also, users 
can display images without dithering and fix the image scale 
during display. 

Image Developer's Kit 

The image team created an image developer's kit that pro- 
grammers can use to create applications built on the HP 
Image Library. The applications developed by programmers 
can be clients of the X server, or they can work solely with 
image files without using X. Most applications access both 
image files and the X server because it is the only means for 
displaying images. 

The toolkit can be installed on HP 9000 Series 700 systems 
and consists of the following components: 

• Header files for the HP Image Library functions 

• A range of sample image files, such as TIFF, GIF. and Xpm 
files 

• Man pages that describe all HP Image Library function calls 

• Source files for sample applications that contain calls to the 
HP Image Library functions 

• Makefiles that convert sample source files into executable 
programs 

• Source files that show how to extend the HP Image Library, 
adding support for other types of files 

• A utility called imageutil that provides command line options 
for image viewing and manipulation. 
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A Printing Solution for a Multimedia 
Environment 



For environments in which users are confronted with a myriad of printers 
to choose from, HP SharedPrint provides a simple graphical interface that 
enables users to select a target printer and a set of options without 
encountering the typical problems associated with this process. 

by John Mandler 



Most computer users in a networked computer environment 
take certain aspects of the system for granted — especially 
shared resources such as disks and printers. Users expect 
these resources to work flawlessly without any concern or 
interference on their part. Unfortunately, the ideal is not 
always possible, especially for printers. Printers often fall 
far short of users' expectations. Because of this, we placed 
special emphasis on providing a robust, easy-to-use printing 
solution for IIP M Power. 

To understand the MP MPower printing solution it is first 
necessary to examine the fundamentals of a spooled print- 
ing system. Fig. 1 shows the phases and basic operations of 
a spooled priming system. 

The user controls the specification phase by selecting an 
output device from a list provided by the system. The object 
(file) to print forms a second part of the the job specifica- 
tion. Finally, any options that control Ihe appearance of the 
final output should be noted. The options may be used to 
control when the job is printed, to define Ihe desired feed- 
back, to select some feature of the output device, or lo 
specify the final appearance of the printed output. 

The queue and control phase is handled by the native spool- 
ing system. It packages the user's job specification, locates 
the target machine, establishes the communication path, 
and places the job in a queue. The spooling system eventu- 
ally dequeues the job, invoking the functions that process 
the job, and directs the output to the printer. The spooling 
system also handles query and control requests from the 
user, providing the feedback required for a robust system. 



The processing phase performs the real work in a printing 
subsystem. This phase is initiated by the spooler, which 
starts a process thai connects a dequeued file to the process 
input and the printer data port to its output port. The pro- 
cessing phase performs the translation and formatting of the 
input data stream, applying options as appropriate, and 
sending out prinler control functions to the Selected printer 
when necessary, 

Problems 

Each of these three steps — specification, queue/control, and 
processing — has problems that can range from nuisance 
issues such as the printer is out of paper lo a compete break- 
down of the printing subsystem (see Fig. 2). Problems in the 
specification phase include the need for the user submitting 
a print job to spend time finding the names and capabilities 
of available printers and spending more time learning how- 
to add special printer control options to a print request. The 
options give the user more control over Ihe final look of the 
document. 

Queue and control problems include minimal to no feedback 
on the slale of a job or printer. Failures are often not re- 
ported to Ihe user, giving the appearance that jobs just dis- 
appeared from Ihe queue. Administering the spooling system 
can be a difficult task. The steps to add a printer are not 
obvious and modifying a printer's default behavior requires 
more knowledge about the printer and programming than 
the user may want to know. 
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Fig. 2. Problems associated with 
some s|>ooIed printing systems. 



The problems encountered during the processing phase can 
be the most difficult to diagnose and fix. Consider that the 
print job process is a background process running on a 
server, which is often remote from the user. If the wrong 
operations are performed on a print job, the result can be a 
hung spooling system, no output, or pages of useless ouiput 
from the printer. Determining the failure requires intimate 
knowledge of the spooling system and any shell scripts or 
programs the spool system executes. 

HP SharedPrint Solutions 

The HP Mpower printing subsystem is based on the HP 
SharedPrint product. It solves many of the printing problems 
mentioned above by providing a robust, easy-to-use subsys- 
tem layered on fop of a spooling system. The HP Shared- 
Print solution addresses the specification phase by provid- 
ing a graphical user interface tool that includes a list of 
printers to choose from and a highlighted list of options that 
can be specified for a particular printer (see Fig. 3). 



HP SharedPrint provides tools that enable the system admin- 
istrator to set up a printer easily and quickly, making customi- 
zation trivial. Another graphical user interface tool provides 
real-time status of print jobs and printers, along with control 
functions to cancel print jobs, add or delete printers, and 
modify a printer's default behavior (see Fig. 4). Both of 
these tools are described in detail later in this article. 

The IIP SharedPrint processing modules eliminate the major 
problems that cause system administrators and end users so 
much trouble. An intelligent server provides print job pro- 
cessing based on an algorithm that dynamically builds and 
executes the elements necessary to handle the job properly. 
Built-in error detection logic is used to provide a hard-copy 
message to the user detailing any problems in processing 
the job. 

HP SharedPrint Overview 

HP SharedPrint has a client-server architecture. The client 
components include the two graphical user interface screens 
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Fig. 3. HPSharedPrlnl graphical 
user interface showing a list of 
available printers. 
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Fig. 4. HP SharedPrint's graphical user interface for system 
administration. 



mentioned above. Fig. 5 shows a high-level view of the HP 
SharedPrint client/ server system. The job specification cli- 
ent communicates with the MP SharedPrint server via the 
base spooling system. The server provides real-time feed- 
back to the user about what options are valid for a specific 
job and printer combination. 

One of the major features of HP SharedPrint is its ability to 
print many of the common file typest transparently on any 
of the supported printers. This functionality eliminates the 
need for the user to know which file types can be printed on 
which devices. 

The HP SharedPrint server, being highly configurable, can 
be used to drive smart as well as dumb printers. Also, be- 
cause of its highly modular design, the server can be layered 
on any spooling system. 

Fig. 6 shows a detailed view of the main components that 
make up the I IP SharedPrint client/server system. The HP 
SharedPrint client contains the graphical user interface pro- 
grams sprint (HP SharedPrint print) and spadmin (HP Shared- 
Print administration ). Sprint prompts the user for the file to 
print ( J in Fig. (5) and the designated printer and then uses 
NCS (network computing services) to connect, to the HP 

t A tile rype is a special data format required ol all printers, such as PCI image files, BTl (taster 
transfer language), PostScript, or applications limage or text) 



SharedPrint feedback server ® and '1'. The feedback server 
hands sprint a set of valid options based on the user's inputs 
©. The option information is used to validate which options 
the user can select for the current job. 

After completing the job specification, the user selects the 
OK butt on in the sprint window to queue the job for printing. 
Al this point the job request moves to the line printer spooler 
(Ip) client The Ip client packages the print request and 
connects to the Ipsched daemon located on the Ip server '« . 
The Ipsched daemon places the job request in the printer 
queue and at the appropriate time starts the IIP SharedPrint 
job processor to process the job (5. 

The HP SharedPrint server includes the HP SharedPrint job 
processor, configuration files that specify various mappings, 
filters, and drivers that perform translation and formatting, 
and the HP SharedPrint feedback server. Data from the con- 
figuration files is used by the feedback server and the job 
processor. The feedback server uses the data to provide 
option information to t he sprint user interface, and the job 
processor uses the data to define the processing steps. The 
job processor invokes the filters and drivers to finish process- 
ing a job. The filters translate and format data files going to 
the selected printer, and the drivers place device-specific 
control information in the data stream going to the printer. 

The Print Client 

The sprint print client enhances the basic HP VUE printing 
model by providing an easy-to-use graphical interface. Sprint 
does not alter or replace the current HP-UX* spooling system 
functionality but is layered on top of the spooling system. 
This leads to a smooth transition from the standard HP-UX 
printing models to HP SharedPrint. The sprint graphical user 
interface allows users to: 

• Select a file to print via a drag and drop operation from the 
HP VUE file manager interface 

• Select a print er from a displayed list of printers 

• Set options based on real-time feedback 

• Save groups of options for reuse later on similar print jobs. 
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The top level interface for sprint is shown in Fig. 3. The 
dimmed buttons represent unavailable items. For example, 
the menu item PaperSource is dimmed to indicate thai the 
selected printer does not support multiple paper trays. 

The button marked Options will take the user to the screen 
shown in Fig. 7. This screen provides another set of options. 
These options are sent to sprint by the feedback server. 




Fig. 7. The Options screen that shows the options available for a 

certain printer 



The Administration Client 

The HP SharedPrint administration (spadmin ) graphical user 
interface is shown in Fig. 4. Selecting the printer icon from 
the HP VUE front panel activates the spadmin client. Print re- 
quest or printer status information is displayed and updated 
every 30 seconds. The Administer menu enables more com- 
plex tasks such as editing printer configuration files, adding 
and deleting printers, and making other changes to the print 
spooler state. 

Core Server 

The IIP SharedPrint core server components are shown in 
Fig. 8. The core server performs lhe processing for a print 
job and provides the options feedback lo the user. Two 
groups of configuration files are used for processing a.job. 
One group contains information lhat defines job processing 
and feedback rules. The other group contains printer config- 
uration information thai defines the default settings and 
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behavior for a particular printer. There is one printer config- 
uration file for each printer connec ted to the system. Filters 
and drivers are standalone programs invoked by the core 
server to process a print job. 

The core server consists of t wo separate processes that 
share a common set of data and some common functions. 
These processes are the job processor and the feedback 
server. The job processor is invoked by the print daemon 
Ipsched with the arguments: 

job_id user_name title copies options files 

The first four arguments represent the job number, the user 
who queued the job, the title of the job, and t he number of 
copies to print. The options argument contains zero or more- 
tokens, each representing an option specified by the user 
queueing the job. For example -charheight 8 -orientation landscape 
are typical tokens in the options argument. These options are 
set in the sprint client or on the Ip command line by prepending 
the letter -o to the option string. The files argument is a list of 
one or more files to be printed. 

The job processor serves all t he supported print ers by 
dynamically configuring itself for each print job. The infor- 
mation needed for this operation comes from the printer 
configuration file. Each printer requires a unique printer 
configuration file, which is created when a printer is added 
to the system. This configuration file can be modified at any 
time via the IIP SharedPrint client spadmin or by using any 
text editor. 

The job processor uses some control programs to read I he 
configuration files to determine which set of Intel's to execute 
to print a job properly. Details of these steps are described 
later. 

The other process in the core server, the feedback server, is 
run on every system where an HP SharedPrint printer is 
installed. This server provides the sprint interface with feed- 
back on what options are valid for a specific file and printer 
combination. 

The feedback server is automatically started when the first 
HP SharedPrint printer is added to the system. Other HP 
SharedPrint printers on the same system use the same HP 
SharedPrint server. 

Configuration Files. The configuration Hies shown in Fig. 8 
are text files that provide all the information necessary to 
process any of the supported file types on any of the sup- 
ported printers. Users can modify any of these files using 
an editor, or in I he case of the printer configuration file, the 
HP SharedPrint system adminisi ration utility spadmin. The 
configuration files include: 

Printer model files. These files contain information for spe- 
cific printer models. For any particular printer model, this 
file includes the options supported, default values for any 
filters, and the file types the printer model can handle. 
Printer configuration file. This file contains information 
about a specific printer. The file is created from one of the 
printer model files when a printer is added to the system. 
Users can modify this file to reflect changes made to the 
printer, such as swapping paper trays or inserting font 
cartridges. Changes take effect at the next print job. 
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• ( Ibjecl name extension file. Tliis file contains a list of entries 
that map file extension values to file types. For example, files 
with the extension c (C source files) would be mapped to 
an ASCII file type. 

• Pipeline file. This configuration file specifies a filter pipeline 
process for each combination of input and output file type. 
Bach of the filter specifications can include options and 
white space. 

• Options map file. This file lists supported options for each 
filter or driver 

• Options file. This file lists known options and aliases. 

• Types file. This file lists known file types and aliases. 

These last five configuration files make up the files labeled 
as job processing and feedback rules in Fig. 8. 

Filters. Filters are programs that transform a data file from 
one format to another. Filters perform either translation or 
formatting. Translators change the encoding of the informa- 
tion in the data file without changing its appearance. For 
example, in converting ASCII text to PostScript format the 
text remains the same, but the file is expanded to contain 
PostScript commands. Formatters modify how the informa- 
tion in the data file will be rendered on the page. For exam- 
ple, a formatter might rotate or scale an image, add com- 
mands for multicolumn text printing, or add footers and 
headers to a document. These filters often have options that 
t he user can set to control the final appearance. 

Filters are invoked by t he job proc essor. Each filter reads 
from standard input and writes to standard output with error 
messages being sent to standard error. The filters supported 
by IIP SharedPrint include: 

• txpcl. This filter formats and translates text documents into 
PCL (printer control language ) format The formatting op- 
tions allow users to change point size, print portrait or land- 
scape, perform double column printing, add headers and 
footers, and change the typeface and symbol-set mapping. 

• txps. This filter formats and translates text to PostScript, it 
also supports most of the options included in the text-to-PCL 
filler txpcl. 

• cgmhpgl2. This filter reads binary COM (computer graphics 
metafile ) format and produces an HP-GL 2 byte stream. It is 
used to obtain 2D graphics output from StarBase or 
HP-PHIGS CGM files. 

• psrip. This filter allows users to print a PostScript file on a 
non-PostScript printer. The filter reads a level- 1 PostScript 
file and creates a raster image for each page. The raster 
image is fed to a device-specific formatter which adds the 
appropriate cont rol or command codes for the target 
device. 

• pclnp. This filter performs the same function as the psrip filter 
on PCL files. The PCL level can be level 1 through 4 and can 
include the level-5 PCL scalable typefaces. PCL 3+, used by 
the HP PaintJet, PaintJet XL and DeskJet 500C printers, is 
not supported by this translator. The HP-GL 2 extension to 
level-5 PCL is also not supported by this translator. 

• ilFilter. This is an image library' filter that converts all HP 
MPower supported image formats, a level-1 PostScript file, or 
a PCL 4 file into a Postscript. RTL, or PCL file. The filter is 
composed of three stages: a producer that converts the input 
object into an image library format, one or more filters that 



manipulate the raster image, and a consumer that converts 
the image library output to a PostScript. PCL, or RTL file. 

Drivers. The function of a driver is to add job control infor- 
mation to the data stream produced by the filters. It does 
not interpret or change the data stream, but adds printer- 
specific commands to the byte stream. Think of the driver as 
handling printer-specific functions, whereas filters handle 
language-specific functions, 

The job control information depends on the target printer. 
Each job control feature in the printer can be selected or set 
by the system administrator when the printer is configured 
or specified by users in their personal options files. 

In most cases the driver will send a header with any job con- 
trol information then cat the input stream from the filters to 
the output stream. In some cases, the driver will have to 
examine the first few bytes of a file to see if there are any 
reset control characters that might interfere with the driver 
header stream. For instance. PCL files may contain an ESC E 
that resets the printer state. The driver will have to strip 
these bytes if a header must be sent. 

Processing Steps 

For each print job, the IIP SharedPrint job processor exe- 
cutes the algorithm outlined in Fig. 9. Each of the steps 
in Fig. 9 represents a module or inline code involved in 
processing a job. 

Parse Command Line. This step is the interface to the base 
spooling system. Each spooling system passes the job data 
to the processing modules in a well-defined form. For the 
HP-l'X spooling system, the job processing module is called 
via the Ipsched daemon with the six command line arguments 
described earlier. The command line information, which 
includes the user name, printer name, job options, and files 
to print is collected and stored in the job proc essor lor use 
as appropriate. 

The main purpose of this module is to enclose the specifics 
of a spooling system in one location so that the process of 
porting HP SharedPrint to a new spooling system would 
involve changing only this module. 

Get Printer Type. A key step in properly processing a job is io 
know (he characteristics of the target device. One such 
printer characteristic is the type of languages or file types 
the printer understands. 

The printer file types are listed in the printer configuration 
file, which is created when a printer is added to the spooling 
system. This step involves parsing the configuration file for 
the target printer. If no file-type entry exists in the configura- 
tion file, or the configuration file cannot be located, an error 
page is sent to the printer, the printer is disabled, and a mail 
message is sent to the user who queued the job. 

Build Options List. Each job includes a list of options and as- 
sociated values. The options list is built from default values 
defined in the printer configuration file, values passed by 
the user, or values added by the filters. User-specified op- 
tions override options defined in the printer configuration 
file or the filters. 

User-specified options can be passed from sprint via the Ip 
command line Since the III' SharedPrint option names are 
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full-length strings, a set of aliases, which are defined in the 
options configuration file, can be used on the Ip command 
line. The build-opt ions-list operation will expand the aliased 
strings when the options list is built. 

Front Banner Page. This step involves building and sending a 
banner page to the printer. This function creates a banner 
page file, then recursively calls the job processor to send it 
t o I he print er. In this way, any type of banner page can be 
sent to any printer. HP SharedPrint includes a banner page 
program for PostScript. PC'L 5. and ASCII text. Fig. 10 is an 
example of the PostScript banner page. 

Get File Type. This step determines the spooled file's file type. 
The job processor must know the file type of a job to deter- 
mine if any processing is necessary to format the spooled 
file for the target printer. For instance, a PostScript file must 
be converted to PCL to print on an HP LaserJet printer. The 
file-typing process uses the following three methods (in the 
order given) to determine t he file type for a job: 

• Command line switch 

• File type reader 

• File extension value. 

When a file type is found from any of these methods, die 
file-typing process terminates. If die file type cannot be de- 
termined from any of the above methods, an error page is 
printed, and the job is aborted. 

• Command line switch. With this method if the user includes 
the file-type option flag (-file_type) on the command line, the 
file-type value wdl be set to the value following the -file_type 
flag. In tiiis case HP SharedPrint assumes the user has some 
knowledge of the file's content that HP SharedPrint cannot 
determine. The sprint program will also prompt the user for 
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Fig. 1 1. The sprint dialog box asking about Hie type. 

the file type if the job processor cannot determine the file 
type. In this case sprint will pop up the dialog box shown in 
Fig. II, asking the user to select one of the values. 

• File type reader. This method compares the spooled file's 
contents with a predefined set of patterns for specific file 
types. These patterns are coded as C programs or Korn shell 
scripts. Each one of these programs or scripts expects a file 
as input. If the file type matches the defined pattern, the 
program or script writes the type siring to standard output 
and returns an exit code of 0 to the calling routine. If there 
is no match, the program or script returns an exit code of 1. 

A special file-type program, based on the image library, is 
used for identifying image tiles. The image library includes a 
set of functions that allow programmers to open a file and 
determine if it is a file type that is supported by the image 
library. If the image library can process the file, the image 
file-type program writes the string "bitmap" to standard 
output and exits with a status code of 0. 

The module that determines a job's file type executes each of 
the file-reading programs and scripts located in a directory 
called filetypes until a match is found. If no match is found 
after all the programs have been invoked, the file extension 
mechanism is used to determine the file type. 

• File extension value. File extensions are used by HP VUE to 
map file types to actions. For example, the extension .au is 
associated with the audio server, a process that plays or 
records audio files. IIP SharedPrint uses many of the same 
extension values, mapping them to a file type in the object 
name extension file. The extension value is extracted from 
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the leal name of the original file that is passed by sprint in 
the Ip spooler title option. 

Build Pipeline. The processing pipeline performs the actual 
work of getting a file printed on the target device. The pipe- 
line consists of one or more filters and a driver, with the 
output of each stage piped into the input of the next stage as 
shown in Fig. 12. 

'Hie pipeline is derived from the printer file type and the 
data file type. The pipeline builder scans the pipeline config- 
uration file looking for file type matches. For each match, 
one or more filters is specified to perform the translation. If 
no match is found for the specified file types, an error page 
is printed and the job is aborted. 

The pipeline is terminated by adding a driver module to the 
filter pipeline. The driver is determined from the printer 
configuration file. The pipeline string at this point will have 
t he format filter 1 Ifilter2 1 driver. Note that each filter might 
be a filler name followed by some options that control how 
the filter is executed. 

The pipeline is completed by adding the appropriate options 
to each filter and the driver. The filler options file maps op- 
lions thai apply i<> each filter or driver so that the correct 
arguments are passed to the filters. The final pipeline string 
might look like: 

txpcl -charheight 8 -orientation landscape I Ij3.sh -copies I 

Execute Pipeline. The pipeline created in the build-pipeline 
stage is now executed. The output from t he lasl stage of the 
pipeline is sen) to standard output, which will be the I/O 
connection to the printer. 

If any errors occur in the pipeline execution phase, they are 
collected and placed on an error page, which is printed at 
the end Of the job. The error page function is called when 
some unrecoverable event occurs. A special log file contains 
all the output from the print script. Each filter or driver 



writes all error or warning messages to standard error The 
job processor redirects this text to the error log. 

At the completion of the job, the job processor scans the 
error log. If any information or messages are found in the 
error log. the job processor builds a text page containing the 
error messages and some debug information and then prints 
the text page on the printer. 

Diagnostic information is included in the error page to aid in 
the analysis of the problem. 

Final Steps. The last -copy step executes the pipeline again if 
another copy is needed, and the last-file step cycles the script 
back through processing the next file if there are multiple 
files lo print. When recycling is required, the initial state of 
the options, printer configuration file, and output lype re- 
main the same and do not need to be recalculated, Finally, 
the rear banner step, which is identical lo the front banner 
page, may be used to print just a short n ailer, or in the case 
of printers that print face up. the banner page should be 
printed here. 

Feedback Server 

The feedback server helps users specify job parameters thai 
optimize the hard-copy output for a given job. Without this 
feedback, users can be easily overwhelmed by the large 
number of available options. By enabling only those options 
that apply to the current job, the feedback server guides the 
user through the job specification process. 

The feedback process shown in Fig. 13 begins with the user 
selecting a file to print on a Specific printer. The sprint pro- 
grain uses the network Computing services (NCS) to connect 
to Ihe server and ask for a lisl of valid options. The feedback 
server executes the algorithm shown in Fig. 13 and returns a 
list of valid options to the client. The sprint program then 
enables Ihe user lo select only Ihe options rciurneii bj the 
feedback server, disallowing (by dimming selections on the 
menu) other options to the user. 
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HP SharedPrint Options 

The options that apply to a given print job are a function of 
not only the target printer, but also any filters t hat may pro- 
cess the job. In the simplest situation, a file whose type 
matches the printer type can be sent without any filtering. In 
this case the set of valid options will be a function of the 
physical features of the printer, such as duplex or paper tray 
selection. 

Even in the case in which the file type matches the printer, 
filters can be inserted to perform some preprocessing or 
formatting. For example, a PostScript document can be 
passed through a filter that places more than one logical 
page on a physical page. 

IIP SharedPrint precomputes the filters that will be used to 
process a job. This information is then used to extract the 
supported options from one of the files containing the job 
processing anil feedbac k rides. It is t his set of options that 
the user sees in the graphical user interface. 

Along with each option is the value attached to that option. 
The filter processing the job must be fed both an option and 
a value. The source of the value comes from one of three 
locations: the user, the printer configuration file, or the Biter, 
in descending order. For example, if the user specifies an 
Option and value, this pair is passed lo the filter. Otherwise 
if a value exists in the configuration file, it is used. Finally, if 
an option and value are not passed to a filter, the filter uses 



a built-in default value for the option. In litis way, the behav- 
ior of a filter is controlled first by the user, then the system 
administrator (via the configuration file), and finally the 
programmer. 

One problem with options is that there is no unified naming 
scheme. Two filters may provide the same functionality and 
use different strings to denote an option. HP SharedPrint 
addresses this by providing the options file to alias filter 
option names to a set of names defined by HP SharedPrint . 

Conclusion 

HP SharedPrint provides HP MPower with a robust printing 
solution. Users can drag and drop any HP MPower object lo 
any printer and use the HP SharedPrint graphical user inter- 
face to control the printing process. The graphical user in- 
terface decreases user frustration, providing an easy-to-use 
printing interface. The intelligent server lowers the system 
administration burden by eliminating catastrophic failures 
and providing the flexibility to customize a printer's behavior. 

PostScript is a trademark at Adobe Systems Incorporated which may Be registered in certain 
jurisdictions 

HP-UX is based on and is compatible with UNIX System Laboratories' UNIX* operating system 
It also complies witb X/Open's' XPG3. POSIX 1003.1 and SVID2 interlace specifications^ 

UNIX is a registered trademark ot UNIX System Laboratories Inc. in ttie U SA and other countries 

X/Open is a trademark ot X/Open Company Limited in the UK and other countries. 
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Faxing Documents in HP MPower 



The ability to transmit documents via standard telephone lines is greatly 
enhanced with the HP MPower fax utility which provides automatic 
dialing, transmission, and delivery of fax documents from a workstation. 

by Francis P. Sung and Mark A. Johnson 



Over the past ten years a revolution has occurred in tele- 
communications that has resulted in the capability to trans- 
mit documents easily and inexpensively using standard 
telephone communication c hannels. The fax machine has 
become pervasive on a global scale and is now a required 
tool for collaboration by all types of businesses. This suc- 
cess can be attributed to the standardization of fax commu- 
nication and the introduction of low-cost, easy-to-use fax 
machines. 

HP MPower fax provides a new level of refinement and 
capability in fax communication. HP MPower fax provides 
the following advantages and features: 
Client/server technology allows each HP MPower fax user 
access to fax capabilities at each user's desktop while shar- 
ing a fax modem at a remote location. This results in lower 
cost per user compared to multiple fax machines and more 
convenient access compared to sharing a single fax machine. 
Online documents can be conveniently faxed by dragging and 
dropping the document on the fax icon in the IIP MPower 
user inlerface. This eliminates the process of printing and 
scanning the document into a fax machine. Document qual- 
ity improves significantly since quality degradation occurs 
during the printing and scanning process. 
The problem of waiting for access to a fax machine is elimi- 
nated. Paxes sent from IIP MPower fax are queued before 
being transmitted. If HP MPower fax is busy sending or re- 
ceiving another fax, the fax wails in the queue and is auto- 
matically sent at a later time. Also, if the destination fax 
machine is busy HP MPower fax will automatically retry the 
fax transmission at a later time. 

Paper use is eliminated. Received faxes can be archived and 
viewed without printing. Online documents can be faxed 
directly without printing. 

Reliability is greatly improved since fax modems are 
inherently more reliable than fax machines. 
Costs are reduced by providing the capability to queue out- 
going faxes for transmission when telecommunication rates 
are lower. Also, faxes that are being sent to the same number 
can be automatically batched together, saving the typically 
higher rale associated with the first minute of transmission. 
A palette of custom fax cover sheets can be convenient ly 
created and accessed. Each custom cover sheet can include 
custom images such as corporate logos as well as fax 
sender information such as name, company, department, or 
any other information the user requires. 
A detailed log of all fax transmissions and receptions is 
kept. This can be used to monitor telecommunication 
charges and generate account billing information. 



• Security of fax access Ls greatly enhanced. Different classes 
of HP MPower fax users can be created with varying privi- 
lege and security levels. Some classes could have the ability 
to send faxes to international fax numbers at any time of 
the day. while other classes might be restricted to local fax 
numbers and transmission times when telecommunication 
rates are discounted. 

• Perhaps the biggest problem with a shared fax machine is 
the inability to route incoming faxes directly to the intended 
recipient. Incoming faxes can be viewed by anyone standing 
near the fax machine and are easily misplaced or lost. To 
avoid this problem, IIP MPower fax can route incoming 
faxes directly to the recipient using a bar code on the cover 
sheet or the origination number of the fax. 

HP MPower Fax Configuration 

HP MPower fax uses a client/server configuration. Common 
functionality used by all HP MPower fax users resides on 
the fax server. Interaction with each fax user occurs at the 
fax client. Multiple fax clients are connected to a single fax 
server via a TCP/IP network connection. A fax client may 
also coexist on the same machine as a fax server. Up to 10 
fax modems can be connected to a single fax server. Each 
fax modem supports a connection to one phone line. Fig. 1 
shows a typical configuration in which HP MPower fax 
operates. 

Major features at a fax client include an OSF/Mot if graphical 
user interface, archival of received faxes, and a user-created 
directory services database of possible fax recipients. Major 
features offered by the fax server include fax modem com- 
munication, rendering, queuing and scheduling of outgoing 
faxes, temporary storage and routing of received faxes, and 
extensive databases for controlling server configuration, 
customization, and automation: 

The process for transmitting a fax begins with the user 
selecting the filet to he faxed from the graphical user inter- 
face at the fax client. The file is then transferred to the fax 
server where it is combined with a cover sheet and rendered 
into the correct TIFF Class F format The fax server then 
schedules the fax for transmission and stores it in a queue. 
When the appropriate time comes for transmission, commu- 
nication with the fax modem begins and the fax is moved 
from the server queue to the fax modem and over the 

telephone line. 



1 Multiple tiles can also be senl (□ the lax server at the same lime 
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When a fax is received, the fax server at the receiving end 
initiates communication with the fax modem and stores the 
incoming fax in temporary storage. If the fax can he routed, 
it is transferred to the appropriate fax client and the user is 
notified. Otherwise, the fax is stored in a general-delivery 
location on the fax server and all fax users are notified. 

The process of transmitting a fax from a client and receiving 
a fax at a server is described in more detail in the following 
sections. 

Fax Client 

The primary component of the fax client is an OSF/Motif 
graphical user interface that, allows sophisticated fax users 
to use the advanced functionality of the fax server while 
also enabling occasional users to send and receive faxes 
easily. The fax client's graphical user interface is integrated 
with HP VUE and other IIP MPower components so that 
tasks such as dragging and dropping files to be faxed, print- 
ing received faxes, and scanning documents for inclusion in 
faxes are easily accomplished. 

The user initiates a fax transmission by selecting the fax 
icon located on the HP VUE front panel or the HP MPower 
media panel. This causes the Compose Outgoing Fax window to 
appear (see Fig. 2). This is the primary window for creating, 
viewing, and sending faxes. An HP MPower fax user can 
send a fax by simply entering t he fax number, dragging and 
dropping the fax attachments (files to be sent), and then 
selecting the Send Fax button. ASCII. PCL, PostScript,™ and 
EFSt files are automatically delected so the user does not 
need to know the file types of the attaciunents. The user can 
then select the Fax Status... button to monitor progress of the 
fax as it is being transmitted. The complete fax with cover 
sheet and attachments can be viewed before sending by 
selecting the View Fax. button. Since the cover sheets and 
renderingtt capability reside on the fax server, the fax client 

t EFS. or extensible file support, is a pari of the HP Image Library F_f S and the HP Image library 
are described in the article on page 37 

1 1 Rendering is any form of drawing operation, including text, line, and raster output. 



Class 2 Fax Modem 

Fig. 1. A typical network config- 
uration in which HP MPower fax 
operates. 

transfers the attachments to the fax server for rendering 
and then moves the rendered fax back to the fax client for 
viewing. 

Advanced features in the Compose Outgoing Fax window are 
configurable so that sophisticated users can easily use ad- 
vanced features without compromising ease of use for occa- 
sional fax users. The default configuration for the compose 
screen is a simple interface in which the user can gradually 
expose and use advanced features as they are learned. 

Advanced features include a directory service database, email 
confirmation of transmitted faxes, handwritten signature 
placement on a fax cover sheet, automatic fax transmission 
at a specified later time (to lower telecommunication costs), 
automatic printing of transmitted faxes, bar code genera- 
lion, and selection of optional styles and classes. The style 
of a fax determines the cover sheet appearance and physical 
size of the fax. Class determines t he priority and parameters 
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for scheduling and transmitting the fax. A directory service 
database can lie created and manipulated on the client that 
contains the fax number, an alias name, and other pertinent 
information about frequent fax recipients. After creating an 
alias entry, the user only has to enter the alias of a fax recip- 
ient, which will cause the fax number and other pertinent 
data to be automatically accessed from the database and 
placed on the fax cover sheet. Multiple fax recipients can be 
grouped together into a group alias ;md saved in the direc- 
tory service database. The user can enter the group alias 
name to send a single fax to multiple destinations at once. 

In addition to file data, two other types of fax attachments 
can be generated from the Compose Outgoing Fax screen. A doc- 
ument scanned in from a scanner attached to the client's 
machine can be attached as part of an outgoing fax. Also, a 
snapshot of any currently displayed window can be captured 
;uid included as part of a fax. 

Received faxes are manipulated from the Browse Received Fax 
SCreeri (Fig. 3). Faxes that have been received can be anno- 
tated) printed, replied to, and archived in user-created fold- 
ers. Typically, a fax is received by the fax server and placed 
in a general-delivery area. All fax users are then notified by a 
change in the appearance of the fax icon symbol located on 
the IIP VUE front panel. When (he user selects this icon, the 
Browse Received Fax screen will appear instead of I he Compose 
Outgoing Fax screen. The cover sheet of any fax in general 
delivery can be viewed from this screen. After viewing the 
cover sheet, a user can claim a fax that appears to be that 
user's own. Claiming a fax moves the fax from general deliv- 
ery on the fax server to an in-box on the fax client where the 
entire fax can be viewed from the Browse Received Fax screen. 
For installations in which confidentiality is very important, 
access lo general delivery can lie limited to a single individual 
user or group. This privileged user or group can view the 
cover sheet of each fax in general delivery and route it t o 
the appropriate in-box. 

Received faxes that have a bar-code symbol on the cover 
sheet can be routed directly to the in-box of the rec ipients. 
The fax server has a bar-code symbol decoder that scans all 
incoming fax cover sheets for a bar code. If a user's bar-code 
symbol is detected, the fax is routed directly lo that user's 
in-box without going through general deliv ery. A bar-code 
symbol can be generated on the cover sheet of a fax trans- 
mitted by IIP MPower fax for reception and routing by other 
I IP MPower fax servers. For reception and routing of faxes 
originating from fax machines, a return cover sheet with the 
user's bar-code symbol can be generated. This return cover 



sheet is transmitted as the last sheet of a fax destined for 
the fax machine. The user at the fax machine can then use 
this return cover sheet as a fax cover sheet when replying. 
This allows faxes originating from fax machines to be 
routed when received by the HP MPower fax server. HP 
MPower fax can be set up to route all faxes that originate 
from a specified fax number lo go to a specified fax user. 
This is useful if all faxes originating from a certain fax 
number are always destined to the same user. 

Fax Server 

The function of the fax server is to allow access to the fax 
resource from multiple fax clients simultaneously, while 
enforcing proper access control, accepting requests for fax 
transmission and scheduling, and receiving and disposing of 
incoming fax transmissions appropriately. To provide these 
services, the fax server is implemented as several programs 
that are run as separate processes. These processes main- 
tain a set of database's and control some private directories 
and files. This complexity provides many of the advanced 
features offered by the fax server. A default configuration is 
provided with the product that allows any fax client to send 
and retrieve fax transmissions immediately after installa- 
tion. With the default configuration, IIP MPower fax is as 
easy to use as a standalone fax machine. 

Fax Server Architecture 

The HP MPower fax server is divided into three major func- 
tional components: the client-connection component, the 
fax-transmission component, and the fax-reception compo- 
nent. Eleven databases control the behavior of these three 
components. Fig. 4 shows the major components and 
databases of the fax server. 

The Circles in Fig. -1 represent programs, some of which are 
run as individual processes while others are invoked by the 
running processes as required. The parallel lines represent 
databases or storage areas. 

The fax server components interact with the information in 
the databases lo handle transmission and reception of faxes 
and communication with clients. The next few sections will 
discuss the databases shown in Fig. 4, and following that, 
the major functional components of the fax server will be 
described. 

Fax Databases 

The eleven fax server databases provide flexibility, configur- 
ability, expandability, convenience, and advanced features 
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Client-Connection Componenl 




such as least-cost scheduling and incoming fax routing, 
These databases can be grouped into three major groups: 
user databases, scheduling databases, and routing databases. 

User Databases. The databases used by the fax server to 
maintain access control informal ion about IIP MPower fax 
users include a permission database and a user database 
(see Fig. 5). 

Permission database. The permission database maintains a 
list of permission groups into which users can be placed. 
Capabilities such as access to general delivery and the abil- 
ity to become a fax administrator can be given to specific 
permission groups. Permissions to connect to the fax 
server, to use specific accounts, classes, dialing rules, print- 
ers, and styles, and to register for a bar code or a caller 
identifier are all granted on a group basis. (Bar codes and 
caller identifiers are used for routing incoming faxes.) 
User database. To connect successfully from a fax client to 
the fax server, the user must be listed in the user database 
and belong to a permission group that has permission to 
connect to the fax server. The user database also controls 
the range of network addresses from which a user can initi- 
ate a connection request. With each user entry, a network 
mask and a network address are kept. When a user invokes 
the fax client, a connection request to the fax server is initi- 
ated. If tiie result of ANDing the network address of the user's 
workstation with the network mask listed in the database 
entry for that user matches the network address in that entry, 
the connection is accepted. Otherwise, the connection is 
rejected. 
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Scheduling Databases. The following databases an? used by 
the fax server when scheduling outgoing faxes: 

• Account database. Each outgoing fax submitted by any fax 
client is required to specify an account to which the call will 
be charged. Each outgoing fax is logged in the account log 
together with the duration of the call and the account to be 
charged. The account database maintains the list of accounts 
available to users. 

• Class database. One of the advanced features of the fax 
server is the ability lo schedule an outgoing fax for trans- 
mission when the cost of the call will be least expensive. 
This feature is called least-cost scheduling, which is con- 
I rolled by the specification of the class of service defined 
for the outgoing fax. The class of service also controls 
which phone lines, if there are more than one in the system, 
are allowed to be used for transmission. If a fax transmis- 
sion should fail because of a busy signal or no answer at the 
receiving end, retry attempts will be made later. The class of 
service also controls the time belween relries as well as the 
maximum number of relries permissible. The class database 
maintains the various features provided for each class of 
service. 

• Style database. The style specified wilh each outgoing fax 
controls Ihe resolution used for the transmission, the paper 



length, and the appearance of the fax cover sheet. Such 
information is maintained in the style database. 

• Fax-line database. The fax-line database tells the fax server 
how many fax modems have been configured for use by the 
fax server. It also contains information necessary for initial- 
izing the fax modems. If the system has more than one fax 
line, not all of them behave identically. For example, some 
fax lines might be connected to regular telephone lines and 
some to leased lines. Because of the different transmission 
lines, the fax-line database contains entries called trunk 
groups, which join together fax lines that have identical 
behavior. When an outgoing fax is eligible for transmission, 
the fax scheduler will pick the unused and least expensive 
fax line from among the trunk groups allowed by the partic- 
ular class of service. Fig. (5 shows the entries in a typical 
fax-line database. 

• Tariff database. Local telephone companies and long dis- 
tance carriers charge different rates depending on the time 
the call is made and whether the call is local or long dis- 
tance (see Fig. 7). The tariff database is used for maintain- 
ing such information about these rates. This information is 
required for the least-cost scheduling feature described 
above for the class database. 
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• Dialing-rule database. Another advanced feat ure of the fax 
server is the ability to convert any given fax number into the 
appropriate suing of numbers to be dialed. With a properly 
set up dialing-rule database, (he fax server can determine if 
it can ignore the area code in a 10-digit fax number if the 
number represents a local call. The server can also deter- 
mine if a fax number needs extra numbers lo add a long 
distance access code. With pattern matching capability, the 
dialing-rale database has the flexibility to fulfill the dial string 
conversion needs of very different syslems such as internal 
telnet systems that require outside line access codes, or sys- 
tems I hat have different access codes for various long dis- 
tance earners. Another function of the dialing-rule database 
is to associate each converted dial string with a particular 



trunk group and tariff entry. Through this association, the 
fax scheduler can determine the least-costly way to send 
a fax. Fig. 8 shows the entries in a typical dialing-rule 
database. 

• Printer database. The printer database maintains the list of 
printers available to the fax server and the associated com- 
mands required to print t he ac knowledgment of an outgoing 
fax. When a fax is Submitted, lite user can select to print an 
acknowledgment of the fax. 

The fax scheduling databases are summarized in Fig. 9. 

Routing Databases. The routing databases are used by the fax 
server to control how incoming faxes are handled for each 
user. 



Scheduling Databases 



Accounts Database 



Accounts lo Be Charged 
lot Outgoing Fax 



Style Database 



Appearance ol Outgoing 
Fax (e.g., Cover Sheet, 
Resolution) 



TariH Database 



Telephone Rates 



Class Database 



Fax-Line Database 



• Number ol Modems 
Connected to Server 



• Trunk Groups 



Printer Database 



List ol Available Printers 
Printer Commands 



Dialing-Rule Database 



Fig. 9. The relationships between 
the scheduling databases. 



Class of Service lor Outgoing 
Fax le.g., Retries, Urgency, 
etc.l 



• Creates Fax Numbers to Be 
Dialed 

• Associates Fax Numbers 
with Trunk and TariH Entry 



58 April lllill Hewlert-Pac-kanl Journal 

©Copr. 1949-1998 Hewlett-Packard Co. 



Action database. The action database maintains actions to 
be performed on incoming faxes on a per user basis. Each 
user can specify a number of action entries, all of which are 
private to the user. Each action entry may include any or all 
of the following types of actions: 

Queue the fax to the in-box of a particular user 

Send email to an email address 

Forward the received fax to a fax number 

Execute some shell command. 
The most commonly used action is queueing the received 
fax to the in-box of the user who owns the action entry. 
Dispatch database. The dispatch database is presented to 
the user as bar-code registration and caller-identifier regis- 
tration. Bar codes are typically associated with faxes sent 
from workstations and caller identifiers are typically the 
telephone numbers associated with standalone fax ma- 
chines. By registering a bar code or a caller identifier, the 
user defines an action entry to be performed by the fax 
server when an incoming fax has a har code on the cover 
sheet or a caller identifier from a fax machine that is similar 
to what is being registered. The user may choose to allow 
other users to register for the same bar code or caller identi- 
fier if it has not been registered and disallowed by another 
user. Typically, bar codes are not shared, while caller 
identifiers may be shared. 

Default Configuration. In the defauli configuration, the user 
database is empty. The fax server will accept any connec- 
tion requests from any fax clients originating from anywhere 
on the network. Any user can submit outgoing fax requests 
using any of the accounts, classes, and styles present at the 
fax server. The defauli dialing-rule database has one entry 
that will match any fax number and dial it as is. The default 
action and dispatch databases are also empty. Thus, all in- 
coming faxes will be left in the general-delivery area. Any 
user is allowed to access the general-delivery area to check 
for received faxes. In this default configuration, the behavior 
of the fax server is very much like that of a standalone fax 
machine. 

Fax Server Components 

The fax server components shown in Fin 1 contain the pro- 
cesses that interact with the fax databases to handle com- 
munication with fax clients, the transmission of faxes, and 
the reception and distribution of incoming faxes. 

Client-Connection Component. The clicni-o eel inn compo- 
nent is the process that communicates directly with fax 
clients. It accepts or rejects connection requests from fax 
clients according to information stored in the user and per- 
mission databases. Once t he connection has been estab- 
lished, the user at the fax client can submit outgoing fax 
requests as well as look at received faxes placed in the 
client's in-box folder. With the right permission, the user can 
also check and claim received faxes stored in the general- 
delivery folder. If the user is a fax administrator, a received 
fax can be routed from the general-delivery folder to the 
in-box folder of another user. 

When an outgoing fax request is submitted to the client- 

coi clion component, the permission database is accessed 

to see if the user is authorized to use the account, class, and 
style specified in the request. The dialing-rule database is 
accessed to See if the tax number matches any of the dialing 



rules the user is allowed to use. From the style specified, the 
cover sheet is located for the request. After these checks the 
appropriate fax Tenderers are invoked to render the cover 
sheet and attachments ( if any) into TIFF Class F images. 
These images and a command file are kept in the fax spool- 
ing area under the directory /usr/spool/fan/destinations. The trans- 
mission component described below will scan this area and 
schedule the fax for transmission. Fax renderers provided 
with HP MPower support ASCII. PCL. and PostScript files, 
and all EFS file types supported by the HP Image Library, 
including TIFF. GIF. JF1F, JPEG. Xpm. Xwd. and Xbm im- 
ages. The HP Image Library is described in the article on 
page 37. 

In addition to submitting and retrieving faxes, other admin- 
istrative operations such as access or modification to any 
entries of the databases are also executed over the connec- 
tion between the fax client and the client-connection com- 
ponent. The user needs to be a fax administrator to request 
such operations. 

The establisliment of a connection between the fax client and 
the client-connection component is mediated by the internet 
daemon inetd. Appropriate entries are made in the files /etc/ 
services and /etc/inetd.conf when HP MPower is installed to let 
inetd know how the connection can be established. If the 
NISt (network information service) is used, the NIS master 
versions of these two files must be modified to include these 
entries. 

Transmission Component. The transmission component con- 
sists of the processes that are responsible for scheduling 
outgoing faxes and transmitting the rendered images to the 
fax modem. The fax scheduler process is responsible for 
scheduling, while the fax Tenderer and fax transmitter 
processes are responsible for rendering and transmitting. 

The fax scheduler is run as a background process. Only one 
such process should run on the system on which the fax 
server is running. It wakes up every minute and scans the fax 
spooling area where all Hie submitted and rendered faxes are 
kept. The command file of each outgoing fax contains the 
class of service information (defined in the class database) 
that the fax scheduler uses to determine whether a particular 
fax is eligible for immediate transmission or not. If the fax is 
eligible for immediate transmission, the fax scheduler checks 
to see if any of the fax lines that, die user is authorized to use 
are free. If a free line is found, the fax transmitter is invoked 
to start the fax transmission on that line. 

If the fax transmission fails because the destination fax num- 
ber is busy or does not answer, the fax will not be eligible 
for retransmission until the Busy^RetryJnterval or No_Answer_ 
Retry Jnterval specified by the class of service for the trans- 
mitted fax elapses. If the fax transmission fails because of 
transmission error, the fax will not be eligible for retrans- 
mission until the Tx Failed_Retry Jnterval elapses. Fax transmis- 
sions that fail after the successful transmission of a number 
of pages will continue from the failed page when retrying 
transmission. If the fax transmission failure reaches the re- 
spective retry limit specified by the class of service, the fax 
will be put in the suspended queue. The user then has the 
option to send it again to the same fax number or to try a 
different Hex number. 

1 the network information service provides global administration ol large network systems 
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Both successful and failed fax transmissioas are logged in 
the account log together with the duration of the calls and 
the accounls used. This helps to rectify fax phone charges to 
specific cost centers. When accessing the account log, regu- 
lar users will see only the fax transmissions they submitted, 
while fax administrators will see all the entries. 

Other operation status information is also logged by the fax 
scheduler and fax transmitter in the system log for diagnostic 
purposes. Only fax administrators can access the system log. 

Reception Component. The reception component consists of 
the processes responsible for monitoring incoming fax calls, 
receiving incoming fax images, and dispatching the received 
faxes. These tasks are accomplished by the fax listener, the 
fax receiver, and the fax dispatcher processes respectively. 

The fax listener is run as a background process. Each fax 
line on the system is monitored by an individual fax listener. 
If an incoming call is delected, the fax receiver is invoked to 
receive the fax images on that line. The fax receiver and the 
fax transmitter are located in the same program. 

When reception of an incoming fax is finished, the fax dis- 
patcher is invoked to determine how to dispose of the newly 
received fax. The fax dispatcher provides one of the ad- 
vanced features of the fax server called incoming fax mut- 
iny in which an incoming fax will be automatically routed to 
its recipient if there is routing information available with the 
fax. This feature is described in detail later. If no routing 
information is available, the received fax is placed in the 
general-delivery folder. Users with general-delivery access 
permissions are able to view the first page of received faxes 
in the general-delivery folder and claim them or route them 
to the correct recipients. This mimics the behavior of a 
standalone fax machine. 

Incoming faxes are logged in the account log. Only fax ad- 
ministrators can see the entries for inconung faxes in the 
account log. 

HP MPower Fax Advanced Features 

The advanced features current ly provided in HP MPower 
fax include the ability to pull together several pieces of 
information to determine the most cost-effective way to 
schedule and transmit outgoing faxes and provide automatic 
routing of incoming faxes. 

Least-Cost Scheduling. When an outgoing fax is submitted, 
the fax server checks the class specified for the fax to deter- 
mine which trunk groups can be used for transmission. Next, 
the fax number is checked against entries in the dialing-rule 
database that the user has permission to use. The dialing- 
rule entry that matches most of the digits in the fax number 
(not counting those matched with patterns) is used if it can 
be used in at least one of the trunk groups found above. For 
each trunk group specified in the dialing-rule entry, the asso- 
ciated tariff is noted and used for determining the least ex- 
pensive way to transmit the fax. The fax server then makes 
a table of time periods within which the fax is allowed to be 
transmitted, together with the costs associated with each 
time period. This information is stored in the command file 
for that fax. 



When t he fax scheduler checks the command file of each 
outgoing fax to see if Uie fax is eligible for immediate trans- 
mission, it first checks to see if the user selected the WaitJo_ 
Send option. If this opt ion is used and the specified time has 
not arrived yet, the fax is not eligible for immediate trans- 
mission. One reason for choosing the Wait_to_Send option 
might be to avoid transmitting when the the receiving fax 
machine is busy. A fax can be delayed for up to 24 hours. 

If t he specified time arrives for the Wait_to_Send option or 
that option was not chosen in the first place, then the dead- 
line lor transmitting that fax is checked. The deadline for 
transmission is specified in the class for the fax. It is mea- 
sured from the time specified in the Waitjo_Send option, or 
from the time when the fax is submitted if the Waitjo_Send 
option is not chosen. If the deadline for transmission passes, 
the fax schediUer will schedule the fax for immediate trans- 
mission, ignoring cost. If the transmission deadline has not 
passed, the fax scheduler will consult the table of time peri- 
ods in the command file to see if the current time falls in the 
least-expensive time period before the deadline for trans- 
mission arrives. If the current time is in the least-expensive 
range, the fax is eligible for inunediate transmission. 

Incoming Fax Routing. When an incoming fax has been re- 
ceived, the first page, usually the cover sheet, of the received 
fax is scanned by the fax dispatcher for a bar code. If one is 
found, the dispatch database is checked to see if such a bar 
code has been registered by one or more users. If found, the 
actions associated with each bar-code registration will be 
performed. Next, the dispatch database is checked to see if 
the caller identifier of the received fax is registered to one or 
more users. If found, t he actions associated witii each caller- 
identifier registration will be performed. Such actions may 
include any combination of routing the received fax to the 
in-box folder of the user, sending email notification to the 
user, forwarding the received fax to a different fax number, or 
executing a user-specified shell script. Forwarding a received 
fax to a different fax number is very useful if the fax recipient 
is temporarily at a different site that can receive fax. 

With incoming fax routing, faxes that are directed to a par- 
ticular user, say by a bar code, can be placed in the user's 
in-box folder immediately without the delays usually in- 
volved when it is placed in the general-delivery area waiting 
for someone to dispatch it manually. Avoiding the general- 
delivery ar ea also provides better confidentiality. 

Other Interfaces to HP MPower Fax Server 

Apart from sending and receiving faxes via the fax client, 
two other interfaces are available for submitting outgoing 
faxes. One of them is the fax email daemon, and the other is 
the simulated printer interface. Note that these interfaces 
provide only a small subset of the functionality and features 
of the fax client. 

Fax Email Daemon. The fax email daemon is run as a back- 
ground process on the machine on which the fax server is 
running. Users who are on a system that cannot execute the 
fax client can send email to faxemd@<fax_server>. where 
<fax_server> is the machine on which the fax server, and thus 
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the fax email daemon, is running. By providing the fax- 
specific header information in the beginning of the email, 
the body of the entail will be sent as a fax by the fax email 
daemon. The following keyword-argument pairs are required 
in the fax-specific header 



Keyword Argument 

From: Sender name, sender title 

Style: Style name 

Class: Class name 

Account Account name 

To: Recipient name, recipient title 

Fax* Fax number 



Only the ASCII contents of the body of the email can be 
sent File attachments are not supported. 

Simulated Printer Interface 

The simulated printer interface, laxlp, allows users to submit 
outgoing faxes as though they are queueing to a printer. The 
command to use is: 



Ip -dlaxlp -o'from: Jane Doe' -o'class Standard' -o . the_file 

where the_file is the file that will be sent as a fax. Here, 
the_file may be an ASCII file or a PCL file. This interface al- 
lows the addition of fax capability to applications that sup- 
port a printer interface without having to make modifica- 
tions to the applications to accommodate a fax machine. 

Conclusion 

The client/server architecture of the HP MPower fax prod- 
uct provides an easy-to-use but full-featured fax capability 
to HP 9000 computers. Its advanced feature of least -cost 
scheduling can save on telephone costs. By minimizing the 
need for human attention, productivity of everyone is in- 
creased. Finally. HP MPower fax enables users to use their 
fax resources more cost-effectively. 

OSF/Motil is a trademark of the Open Software Foundation In the U S and oiher countries 
PosiScnpl is a trademark of Adobe Systems Incorporated which mav be registered in certain 

lunsdictions 
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Audio Support in HP MPower 



Multimedia capability promises to enhance the communication and 
presentation of information through the use of real-world data types such 
as audio and video. Compact-disk-quality audio is the first of such data 
types to be offered as a standard feature on all of HP's new workstations. 

by Ellen N. Brandt, Thomas G. Fincher, and Monish S. Shah 



IIP MPower provides the hardware and software to allow 
recording and playing of audio files over a network, incorpo- 
raling audio in email, adding audio annotations to system 
files, and recording and playing to external devices like tape 
recorders, CD players, and VCRs. With these capabilities 
audio-enabled applications can add voice annotation to doc- 
uments ranging from spreadsheet rows and columns to CAD 
drawings. Programmers might add audio comments to their 
programs. Error messages could take the form of spoken 
messages, or even distinctive sounds that convey more in- 
formation than a simple beep. Finally, background music 
could be added to presentations. 

This article describes HP MPower's audio functionality, 
application development tools, and audio hardware and 
software architecture. 

Audio Tools 

The audio tools provided in HP MPower allow users to re- 
cord, edit, and play audio data in a variety of file and data 



formats. HP MPower also provides tools for converting be- 
tween audio formats. All of these tools are built on the audio 
library, which defines the application program interface to 
HP MPower's client/server audio implementation. The appli- 
cation program interface, libraries, widgets, and header files 
are available (o third-party software developers who wish to 
use audio in their applications. 

The Audio Editor. The audio editor is based on OSF/Motif 
widgets and audio library (alib) functions. The audio editor 
enables the user to record, play, and edit audio files in a 
variety of file and data formats. It displays a waveform rep- 
resentation of the data to make editing easy and supports 
basic editing tasks like selecting, cutting, and pasting. The 
main screen for the audio editor is shown in Fig. la. 

The audio editor can be invoked or redisplayed by clicking 
on the audio icon on the HP MPower media bar. Dropping a 
file from the IIP VlJE file manager onto the audio icon will 
bring up the audio editor with the file already loaded and 
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displayed. A file can be loaded into an already visible audio 
editor by dropping the file icon onto the editor screen. 

Audio Control Panel. The audio control panel is an OSF/Motif 
interface to global audio parameters such as volume and 
output device selection (see Fig. lb). All cooperating audio 
applications can use trie control panel so the user always 
knows where to go to control these attributes. The audio 
control panel also provides a Stop burton that will stop the 
current play operation from any cooperating application. 

The audio control panel allows the user to turn monitoring 
on or off. Monitoring involves listening to the audio input 
signal. In a conventional tape recorder, monitoring allows 
the user to listen to the audio signal being recorded. On a 
workstation that has HP MPower, monitoring can be used 
whether or not anything is being recorded. For example, a 
user can monitor the workstation's line inputs from a CD 
player or VCR even when recording is not in progress 
without using the CPU or other system resources. 

Audio Playback. An audio file can be played by simply 
double-clicking on the file's icon in the file manager or in an 
audio-enriched mail message. The file will begin playing 
according to the settings of the audio control panel. A file 
can also be played by dragging its icon from the file manager 
to the speaker icon on the HP VUE front panel. 

Other Functionality. In addition to the graphical interfaces to 
audio functionality mentioned above, there are some other 
capabilities shipped with HP MPower that are accessible 
from a command line. In the directory /usr/audio/bin execut- 
ables for the audio editor ( audio_editor ), the audio control 
panel (AudioCP), the double-click function (send.sound ), and 
the convert and attributes programs are provided. The con- 
vert program converts audio files from any supported file 
format, data format, and rate and number of channels to any 
other format and rale. The attributes program tells every- 
thing that it can determine or guess about any audi< > file 
including file format, data formal, sampling rate, number of 
Channels, data length, and header length. 

Audio Data and File Types 

A number of audio data and file types exist in the industry 
today, making it difficult lor audio files to be shared in a 
heterogeneous environment. 

The lack of standards for audio is currently being addressed 
by groups such as the IMA (Interactive Multimedia Associa- 
tion). This organization and others are trying to develop 
standards so that someday there will be a clearer picture as 
to how to store audio information in a format that is accessi- 
ble to everyone and can be easily incorporated with other 
aspects of multimedia. 

In the meantime, we chose to support two of the existing 
file formats and to develop conversion utilities that allow us 
to support sampling rales, data formats, and byte ordering 
methods that are not supported directly by our audio 
hardware. 

File Format A file format is a structure in which there is infor- 
mation about the data as well as the data itself. This infor- 
mation may reside exclusively in a header at the beginning 
Of the file or may be interspersed in "chunks" throughout the 



file. In the latter case, it is possible that only certain types of 
chunks are pertinent to audio. 

Pertinent information for audio files includes the sampling 
rate, data format, number of channels, compression tech- 
nique, and number of samples. Sometimes there is additional 
information such as loop points or edit markers. 

The two audio file formats we chose to support include 
Microsoft ' RIFF/Waveform. which is chunk-based, and the 
NeXT/Sun audio format, which is a file header followed by 
data. 

We also support audio files that contain only the raw sam- 
ples. Although this is a popular method of storing audio data 
and it can be useful in a heterogeneous environment, we 
recommend using a file format with a header whenever pos- 
sible because the attributes of the audio data cannot be 
determined from the samples themselves. 

Data Format. Data format defines the method in which audio 
samples are stored. The most basic method is linear PCM 
(pulse code modulation). The signed amplitude of the audio 
waveform is quantized at fixed intervals of time. Each step 
of the quantization has equal size. This format is very easy to 
work with and is preferred by most audio editing and mixing 
routines. One of the formats that our audio hardware sup- 
ports is the 16-bit linear PCM, which is used by compact 
disks and is popular on UNIX*-system-based workstations. 

An unsigned version of 8-bit linear PCM is very popular 
among Macintosh and PC users because instead of having 
an amplitude range of -128 to +127, unsigned (or offset) 
8-bit linear has an amplitude range of 0 to 255. All samples 
arc offset by 128. For example, silence, which is normally 
quantized as 0, is recorded as 128. 

We also support the CCTTT (International Consultative 
Committee for Telephone and Telegraph) |i-law and A-law 
Standards. These are companded PCM formats. In these 
formats the straightforward linear scale is replaced with a 
base-eight logarithmic scale such that there are small step 
sizes at low signal levels and large step sizes at high signal 
levels. The result is a better signal-to-noise ratio and the 
ability to represent the dynamic range of 115-bit or 14-bit 
samples with only 8 bits, u-law and A-law both specify 8-bit 
samples at 8000 samples per second, u-law is very common 
on UNIX-system-based workstations. An overview of the 
A-law and u-law data formats is provided on page 65. 

Sample Rate. The sample rate refers to the number of digital 
samples used to represent one second of analog audio. The 
greater the number of samples, the more accurately the 
audio signal will be reproduced. A sample rate of 8 kHz 
(8000 samples/s) can reproduce human voice with adequate 
clarit y, but it does a very poor job on music. For music, 44.1 
kHz (44,100 samples/s) works well. The music on all com- 
pact disks is recorded at this sample rale. Digital audio 
tapes (DAT) have a 48-kllz sample rate, producing slightly 
better audio quality. The audio hardware (described later) 
supports all of these sample rates plus a few Others. 

The sampling rale is also subject to the Nyquist criterion, 
which dictates thai the sampling rale must be at least t wice 
the rate of the highest frequency being recorded. I Uglier 
frequencies will typically he filtered out by the recording 
hardware. 
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Fig. 2. Client/server architecture for the audio software. 

Multiple Channels. Although audio files with more than two 
channels do exist, most are either mono (one channel) or 
stereo (two channels). The two channels in a stereo file are 
typically interleaved on a sample by sample basis. This 
means there will be a sample for I he left channel, followed 
by one for the right, followed by the next one for the left and 
so on. 

Byte Ordering. One problem with supporting files across a 
heterogeneous environment is that the byte ordering of the 
local hardware may be different. In our audio Structure we 
supply information about the byte ordering of the audio 
hardware connected to the system. Unfortunately, there is 
no easy way to determine the byte ordering of the audio data 
in a file that is imported from elsewhere. Therefore we are 
forced l.o make assumptions. We assume all RIFFAVavefonu 
files use least-significant-byte-first order and that all other 
files use most-signifieant-byte-first order. This applies even 
to the files created by our audio tools. 

Client/Server Architecture 

The audio system software uses a client/server architecture 
that is modeled after the X Window System (see Fig. 2). The 
client side provides a consistent interface to application 
programs and handles the connection to the server, which 



may be local or remote. The server side provides a consis- 
tent interface to the client side, handles control of the audio 
device, and performs data I/O. 

The audio server (aserver) interfaces multiple clients to the 
audio hardware, allowing simultaneous play and record, 
queuing of mult iple play and record transactioas, priority 
preemption, and dynamic buffering. 

The audio server also supplies information to the client side 
about the attributes of the connected audio hardware. The 
audio library provides the capability to convert various audio 
att ributes to ones that are supported by the connected hard- 
ware. Therefore, the hardware attributes (sampling rates, 
daia formats, byte ordering, etc.) do not need to be the same 
on the client and the server. 

Support for Application Developers 

Since our audio software subsystem is closely modeled after 
the X Window System and OSF/Motif, we provide a library, a 
server, widgets, and a toolkit that are very similar to their X 
counterparts. When appropriate, we followed the X conven- 
tions in our implementat ion of the various components. For 
example, the naming convention, function argument conven- 
tion, and event and error handling of the audio library all 
follow the conventions used in Xlib. An application devel- 
oper who is familiar with X and OSF/Motif should find it 
easy to incorporate audio functionality. 

The audio server handles the interface to the audio driver 
and prov ides control of audio transactions. This isolates the 
audio client from hardware-specific device calls and allows 
a higher level of transaction control than would otherwise 
be possible. 

Hie audio library is conceptually much like the X library, or 
Xlib. The audio library provides the low-level application 
program interface for audio. The audio libraty provides 
functions that allow an application to connect, to one or more 
audio servers, to manipulate the configuration of the audio 
hardware controlled by the servers, to control recording 
from a server to a file or data stream, and to control play- 
back from a file or data stream to a server. The audio library 
also provides the capability for applications to play audio 
from any of several popular file and data formats and to 
save audio in any of those formats. 

The audio widgets provide high-level access to record arid 
play functionality. The application developer can use the 
widgets without having to learn the lower-level audio library 
calls. The audio widgets don't export all the functionality of 
the audio library, but they do provide some flexibility 
through the use of resources that can be specified by the 
client application. 

The audio toolkit provides callbacks for audio events. Since 
it is not desirable for audio events to interfere with other 
events when an application is using the X toolkit, the audio 
toolkit allows the X toolkit to detect audio events and call 
the audio toolkit event handler. 

Several example programs are also provided for developers. 
These include the source code and Makefiles. Some of the 
examples use the widgets and toolkit, and others use only 
the low-level audio library calls. 

Icontinued on page 661 
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Overview of A-Iaw and u-law Data Formats 



An analog audio signal is continuous m time and amplitude If ig lot In contrast, a 
digital audio signal is discrete m time and amplitude An analog-to-digital con- 
vener is used to convert an analog audio signal to digital format This conversion 
consists of two separate steps sampling and quantization Sampling converts the 
analog signal trom continuous time to discrete time by capturing the value of the 
analog signal at regular intervals in time Theoretically, the sampled signal only 
has a value at those sampling times Fig 1b shows the sampled version of the 
signal in fig. la. 

The process of Quantization maps each sample value to a number These numbers 
are represented with a fixed number of bits, giving them limited precision The 
quantization process picks the number that best approximates the amplitude of the 
sample. Essentially, each step in the digital code represents a quantum of increase 
lor decrease) in the amplitude Hence the name, quantization Fig. 1c shows the 
signal after quantization, along with the digital codes assigned to each quantiza- 
tion level A digital audio stream is simply a sequence of such digital codes. Al- 
though Fig lc shows only a few quantization levels, actual implementations use 
thousands of levels 

The most straightforward form of quantization uses fixed-size quanta of ampli- 
tude. In other words, each step in the digital code represents the same step size in 
amplitude In this scheme, the mapping from amplitude to digital codes can be 
represented with a linear function (known as linear quantization! Fig 2a shows a 
linear mapping function 

A-law and u-law define a kind of mapping in which the digital code is roughly 
equal to the logarithm of the amplitude. Although both laws use the same basic 
idea, the actual mapping equations are somewhat different in the two laws Also, 
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to simplify the conversion to or from linear quantization, a piecewise linear 
approximation is used Fig 2b shows a logarithmic mapping function and its 
piecewise linear approximation 

Telephone companies use A-law and u-law to carry long distance conversations 
because these formats save bandwidth For telephone conversations, signal 
strength may vary as much as 30 dB because some callers have softer voices than 
others, or some microphones are more sensitive than others It is necessary to 
maintain a 35-dB signal-to-noise ratio ISNRI over the entire range. With linear 
mapping, quantization noise remains independent ol the amplitude level, so one 
must design for 65-dB signal-to-noise ratio 130 dB ♦ 35 dB) to meet the require- 
ments. As the signal strength varies over the 30-dB dynamic range, the SNR vanes 
between 35 dB and 65 dB. This solution delivers a higher SNR than required at 
most amplitudes lo meet the SNR requirement at minimum amplitude The price 
for exceeding the SNR specification in a linear mapping scheme is that 12 bits per 
sample would be required However, using A-law or u-law, 35-dB signal-to-noise 
ratio can be maintained over a 30-dB amplitude range with |ust eight bits This 
works because logatithmic mapping has the property that larger signal amplitudes 
result in larger quantization steps Thus, quantization noise is proportional to Ihe 
amplitude, maintaining a reasonable SNR across a broad dynamic range This is a 
more efficient way to use the quantization levels, making eight bits per sample 
adequate Thus, the use of A-law or ii-law results in a 33% reduction in telephone 
audio transmission The same benefits are realized in computer audio. 

The differences between A-law and n-law are minimal The USA , Canada, and 
Japan use u-law for telephone transmission, whereas most other countries use 
A-law lor telephone transmission While A-law is somewhat easier to implement, 
u,-law provides slightly better quality at low amplitudes Note that A-law and 
It-law work well with voice audio only For high-fidelity music reproduction, linear 
mapping with 16 bits per sample is typically used. 
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Audio Hardware 

While audio components such as microphones and speakers 
work wilh analog signals, the workstation CPl 1 manipulates 
dala iii digital form. Thus, to record audio on a workstation, 
the analog audio signal must be converted to digital fond 
using an analog-to-digital converter. Similarly, audio play- 
back requires a digital-to-analog converter. The addition of 
these components turns a workstation into a versatile lape 
recorder — one that can provide rapid access to a large num- 
ber of audio clips and associate them with other dala types 
within the workstation. 

By supporting several options for sample rates and data for- 
mats and offering a choice of stereo or monophonic sound, 
the audio hardware used on HP 9000 workstations allows 
the user to make the appropriate trade-offs between quality 
and slorage requirements. For example, higher sample rates 
result in better quality, but also require more storage. The 
user has the freedom to choose the appropriate quality. 

The audio inputs and outputs are compatible with most con- 
sumer equipment, which allows easy connectivity. Two types 
of inputs are offered on our audio hardware: microphone 
and line in (for VCRs and compact disks). Only one of these 
may be selected at any given time. Three outputs are avail- 
able: speaker, headphones, and line out. Any combination of 
outputs may be activated simultaneously, but they will all 
output the same signal. Although the audio design supports 
these five types of inputs and outputs, some workstations do 
not contain all five connectors because of space restrictions. 
Input and output may be activated simultaneously, which 
means that simultaneous recording and playback is allowed. 

Audio under the UNIX Operating System 

Audio presents a special challenge to a UNIX system because 
audio is an isochronous data type. Isochronous means con- 
stant with respect to time. This implies thai the system must 
process audio samples at exactly the specified sample rate. 
If it slows down or speeds up, the listener will perceive dis- 
tortion in the audio. Unfortunately, the UNIX operating sys- 
tem was not designed to work with isochronous data types. 
In fact, the UNIX system supports multitasking, which 
means that the CPU splits its effort between any number of 
tasks that might be active. Obviously, when there are more 
tasks outstanding, each task gets less time from the proces- 
sor. This makes it impossible to guarantee that the audio 
hardware will gel as much processor time as it needs. 

Even the hardware infrastructure of the workstation can 
interfere with audio operation. Just as the CPU cannot guar- 
antee adequate attention to audio, the system bus cannot 
guarantee adequate bandwidth for audio. The audio hard- 
ware design team's challenge was clear: overcome these 
difficulties while maintaining low cost. 

The Solution 

The problem desc ription above makes it dear that a solution 
that guarantees isochronous Operation under all conditions 
does not exist. The designers instead chose an approach 
that achieves isochronous operation under most conditions. 
That approach calls for putting a reasonable, not worst-case, 
upper bound on the delay for any given operation and com- 
puting how much audio data could be consumed or produced 
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Fig. 3. BlOck diagram of Hie audio I/O hardware within a simplified 
representation of a portion of a workstation. 

in that time. A FIFO buffer of that size is required to cover 
thai delay. For example, a heavily loaded CPU may shift its 
attention away from the audio tasks for one or two seconds. 
Therefore, more than two seconds of audio is typically buff- 
ered in system memory. (Actually, the user can vary the size 
of that buffer if necessary. A system that is often heavily 
loaded might need a larger buffer. ) 

Two Options exist for moving audio data between system 
memory and the audio hardware. Either the CPU can move 
il in response to an interrupt, or the audio hardware itself 
can move it. Since the CPU often turns its attention to other 
things, it might take several milliseconds to respond to an 
interrupt. Under the design philosophy described above, the 
audio hardware would need to buffer enough data to cover 
that delay. To provide adequate storage space, a separate 
memory chip would be required, making the audio hardware 
somewhat more expensive. On the other hand, the audio 
hardware could access the data using direct memory access 
(DMA). To perform DMA, the audio hardware must become 
I he master of the system bus. The delay for getting master- 
ship is on the order of tens of microseconds, and the buffer 
most be able to cover that delay. The DMA approach re- 
duces the size of the buffer by two orders of magnitude. In 
fact, in the final design, the required buffer size is small 
enough to implement inside a simple gate array (see Fig. 3). 
The gate array is required to interface to the bos anyway, so 
the cost increase was negligible. Of course, the DMA logic 
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added design complexity. Thus, cost was reduced through 
increased R&D effort. To make the audio hardware inexpen- 
sive enough to offer it as a standard feature, the engineering 
trade-offs had to favor lower cost. 

Physical or Virtual DMA? 

All modern workstations employ a virtual memory system 
that allows the CPU to work with virtual memory spaces that 
are larger than the physical memory available in the system. 
All programs access memory using a virtual address, and the 
CPU hardware translates it to a physical address. In con- 
trast. DMA accesses do not go through that same hardware, 
so the hardware initiating a DMA request must supply the 
physical address to the bus. In that sense, IIP workstations 
do physical DMA, not virtual DMA. Still, an I/O device could 
include the hardware necessary to do virtual-to-physical 
translation, effectively giving that device the ability to do 
virtual DMA. Since programs work with virtual addresses, 
they could communicate with I/O hardware more easily if 
that hardware did virtual, rather than physical DMA. 

Unfortunately, virtual-! <>-physical translation hardware adds 
complexity and cost to 1/0 hardware. For that reason, our 
audio hardware does not do virtual DMA. Instead, the driver 
software assumes I he responsibility of presenting the hard- 
ware with physical addresses. Again, the trade-off was made 
in favor of lower system cost. 

Hardware Components 

Fig. 3 shows a block diagram of the audio hardware compo- 
nents within a simplified representation of a workstation. As 
shown in I he figure, the audio hardware connects to the 
workstation's system bus. The CPU uses the system bus to 
initialize I he audio hardware with the desired parameters 
such as sample rate, volume level, and so on. The DMA 
block uses the system bus to read audio data for playback 
and to write audio data for recording. It writes the playback 
data into the playback FIFO and reads the recorded data 
from the record FIFO. Each FIFO's size is 8 words by 32 
bits. The oilier ends of the FIFOs connect to the serial inter- 
face block. This hardware converts audio data from parallel 
form, which the FIFOs use, to serial form, which the audio 
CODEC requires. The term CODEC is an abbreviation for 
coder/decoder. In thus context, analog-to-digital converters 
are called coders and digital-to-analog converters are called 



decoders. The audio CODEC implements two converters of 
each type in a single chip, allowing stereo operation. Some 
of the CODEC inputs and outputs are buffered with analog 
amplifiers. In some cases, the amplifiers provide more gain, 
while in others they help match input or output impedance. 
The CODEC also implements the logic required to support 
the various sample rates and data formats discussed earlier. 
The analog-to-digital and digital-to-analog converters inher- 
ently operate with Hi-bit linear data So, if A-law or u-law 
mode is selected, the CODEC converts playback data from 
the selected mode to 115-bil linear and recorded data from 
16-bit linear to the selected mode. 

The CODEC is a commercially available part. A single gate 
array implements the rest of the logic in the audio hardware. 
Some salient features of this HP-designed gate array are: 

• 4,953 gates 

• 1.0-micrometer technology 

• 120 PQFP (plastic quad flat pack ) package. 

The process used for this gate array allows finer -pilch I/O 
pads than most similar processes. The finer pilch is better 
matched to the particular ratio of gates to pins of this chip. 
If manufactured in another process, this chip would have 
cost more because of a larger die area 

Conclusion 

For audio to be useful on the desktop, audio capabilit ies 
must be pervasive. The HP 9000 Series 700 workstations 
have kept the cost of audio hardware and applicat ion devel- 
opment low by avoiding special-purpose hardware like digital 
signal processors in favor of using the power of the PA-RISC 
processor to handle digital audio signals. This allows IIP to 
ship high-quality audio with every workstation. Our audio 
offering is completed with an audio server and basic audio 
lools to get users started with audio, and a library contain- 
ing audio widgets, a toolkit, and program examples for 
application developers. 
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Video Support in a Multimedia 
Environment 



Combining video with the computing power of a workstation adds an 
extra level of interpretation, detail, and perception to information seen 
and manipulated on a workstation desktop. 



by Craig S. Richard 



Wo have all heard the expression "a picture is worth a 
thousand words." Images convey meaning that is dilTicul! lo 
express jusl using words. For example, consider the diffi- 
culty in Hying to describe in words a person's looks, a shade 
of color, a complex object, or a CAT-scan image. You can use 
a lot of words to create a menial image of I he object being 
described and hope thai Ihe words are interpreted as you 
intended, or you can show a picture. Video takes the value of 
images a slep furl her by presenting 30 interrelated pictures 
every second. 

We live in a time when video is one of our primary sources of 
information. We depend on video on a daily basis to provide 
us with the information we need or desire. The television set 
is the focal point of many homes. We watch television to see 
the latest breaking news, to see what the weather is going to 
be like the next day, to see places and things that we may 
never be able lo see in person, and simply for entertainment. 
Video gives us Ihe perception of "being there" as we watch 
it. We experience the event rather than create our own inter- 
pretation of it, and we remember the experience in more 
detail. 

Why Video on a Workstation 

Obviously, buying an expensive workstation just to watch 
television renins, sports events, or any other broadcast tele- 
vision shows doesn't make a lot of sense. So why would it 
be useful to have video on a workstation? A simple answer 
is that video can add a new dimension for doing many kinds 
of work. For example, consider a mechanical test engineer 
who must validate a computer simulation based on the de- 
sign data with Ihe actual physical behavior of a mechanical 
part. Typically, this is done by first analyzing Ihe behavior of 
the mechanical part on Ihe computer using a 3D modeling 
package. By having the physical behavior available as video 
information on the workstation, the mechanical part can be 
simultaneously analyzed with its computer model. The accu- 
racy of the analysis and the ease and efficiency of testing 
would be greatly enhanced. This is just one example of the 
advantage of having video functionality integrated into a 
workstation, and the added value that computers can bring 
to video. 

Using a computer is inherently an interactive experience. 
The user provides input through a keyboard, a mouse, or 
some other input device and the computer responds, takes 
some action, shows the results of that action, and waits for 



the user to provide more input. Watching television is a pas- 
sive experience. The viewer typically doesn't interact with 
the picture on the screen. 

As computer technology mid television technology con- 
verge, the result is the power and impact of video with the 
control and interactive capability of computers. This is 
where the advantages of video capability on workstations 
become apparent. By combining text, graphics, audio, and 
video into an interactive presentation, the user can quickly 
and efficiently gather information on demand with a high 
rate of retention. This is invaluable for on-the-job training 
where an employee may need to leant (or releani) a very 
specific task very quickly. As an example, take an automo- 
bile assembler who may work on engine assembly for a few 
months and then work on front-end assembly for a few- 
months, and so on. This is a situation in which interactive 
video and workstation capabilities can be combined with a 
computer-based training course to provide some quick and 
inexpensive training as the assembler moves from one type 
of assembly station to another. 

Challenges in Video Technology 

Although video provides a vast amount of information. Ihe 
delivery of video also requires a vast amount ofdigiinl data. 
A video image on a monitor is composed of hundreds of 
thousands of dots of phosphor (pixels) that are illuminated 
(at different intensities) by an electron gun as it scans across 
Ihe monitor. The gun scans horizontally across a line of pixels, 
and then skips down to the next line and scans horizontally 
across the new line until the entire monitor is scanned. The 
electron gun then jumps back lo the top of the display and 
begins scanning across the lines again. The whole process is 
repeated 30 to 75 times a second depending on the refresh 
rate of the monitor. 

For television, the intensity of each pixel is detennined by a 
voltage representing an analog signal received from a video 
source such as a VCR or cable TV timer. The signal changes 
continuously to represent the color and intensity of each 
pixel 

In the computer, the intensity of each pixel is determined by 
a voltage representing a numerical value in a specialized 
computer memory called a frame buffer. In a simplified 
black and white model, there would be one bil of memory 
representing the intensity of each pixel. If the bit is on. the 
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pixel on the monitor would be white, and if the bit is off, the 
pixel on the monitor would be black. More information is 
required to represent color images. To display 256 colors 
simultaneously (the most common workstation graphics 
capability J, eight bits of information is required for each 
pixel. To represent true color (four million colors). 24 bits 
of information is required for each pixel. 

To change the color or intensity of a pixel, a different value 
must be written into the frame buffer memory location thai 
represents that pixel. For static, computer-generated images 
such as text and grapltics, the memory values do not need to 
be updated frequently. The border around the window, or 
the icon on the top of the screen may not change for hours. 
However, for animated sequences, the memory' values repre- 
senting the pixels need to change for each new image. For 
video, this means that the memory value for each of the hun- 
dreds of thousands of pixels has to be changed 30 times a 
second! In the United States, there is a standard video liming 
format, NTSC (National Television Standards Committee), 
which allows for a video image that is 640 pixels wide and 
480 pixels high. If the NTSC signal were represented in true 
color, there would have to be three bytes of information for 
each pixel. This corresponds to 900K bytes of information 
for each image, and with images changing 30 times per sec- 
ond, over 26M bytes of information would need to be written 
every second. This is an enormous amount of information to 
move around every second. 

HP VideoLive Requirements 

Video technology in HP MPower has been provided by HP's 
VideoLive product. VideoLive was developed by RasterOps 
Corporation exclusively for HP. HP engineers specified the 
requirements for the video capability, and RasterOps de- 
signed and produced a pnxlucl thai tnel the requirements. 
There were four main design requirements. The first require- 
menl was to provide full-motion (30 frames per second) 
video in a window on an HP 9000 Series 700 Workstation 
monitor. The window had lo be movable to any position on 



the display, uniformly scalable, and ocdudable by other 
windows on the display. 

The second requirement was that the video product had to 
work with existing HP graphics subsystems. At the time, 
most video implementations required a frame buffer that 
was shared by the graphics and the video. HP produces 
some of the highest-performance graphics frame buffers in 
the world, and nobody would be willing to sacrifice high- 
performance graphics for video functionality. 

The third requirement was that displaying video images 
should not adversely affect system or graphics performance. 
If the CPU were required to display video information, the 
system would need to allocate most ( if not all) of its process- 
ing power to the video. In a shared frame buffer implementa- 
tion, even though the CPU is not rendering the video, there 
is contention between the CPU and the video when the frame 
buffer memory is accessed, resulting in the degradation of 
graphics performance. 

The fourth requirement was that although watching video on 
a workstation has definite value, the ability to capture the 
video information has even more value. Therefore, it had to 
be possible to capture individual video frames in digital form. 

VideoLive Hardware 

To meet the design requirements, an analog mixing scheme 
is used to generate video frames on the display. VideoLive is 
a single slot EISA card. The card has an on-board 1024-by- 
512-by-24-bit video frame buffer into which an analog video 
signal is digitized in real lime. 'Hie digitization is accom- 
plished using a Philips SAA7191 video decoder and an 
SAA7192 color space convener. The contents of the frame 
buffer are stored in ROB format (<S bits of red, 8 bits of blue, 
and 8 bits of green). A Brooktree Bt463 digital-to-analog 
converter (RAMDAC) is used to generate the analog signal 
thai drives the monitor. Fig. 1 shows the architecture for the 
VideoLive card. 
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Fig. I. Simplified block diagram 
Of HP VideoLive hardware. 
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The RGB Output from the graphics frame buffer's RAM D AC 
is connected directly to the VideoLive card instead of to the 
monitor. Using a high-speed multiplexer, the RGB output 
from VideoLive's video frame buffer is mixed with the RGB 
output from the graphics frame buffer. A set of program- 
mable registers are used to specify the position and size of 
the video window. 

The need to capture digitized video frames is met by digitiz- 
ing the analog video in real time into a frame buffer. When 
grabbing frames, the video image is momentarily frozen in 
the video frame buffer and then the CPU reads the contents 
of the frame buffer (in RGB format) over the EISA bus and 
into system memory. 

By taking advantage of the IIP Image Library capabilities, the 
captured frames can be saved in a TIFF file and can option- 
ally be compressed using the JPEG compression algorithm. 
Once in TIFF format, the captured frames can be printed, 
faxed, and viewed by IIP ImageView, and pulled into ihe IIP 
SharedX Whiteboard application to be viewed and anno- 
tated over the network by several people. HP SharedX and 
Whiteboard are described in the article on page 23 and the 
IIP Image Library is described in the article on page 37. 

X Video Software 

Live video functionality is tightly integrated into the IIP VUE 
environment. This is accomplished using the X video exten- 
sions (Xv) to the X window server (see Fig. 2). Xv is a de 
facto standard for providing live video functional i i y for 
applications based on the the X Window System. 

Xv provides the hooks through which X window geometry 
events such as position changes and clip rectangles can be 
relayed to the video window. When an Xv window is active, 
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all geometry events to that window are intercepted by the Xv 
software. The Xv soft ware renders a black area on the 
screen onto which the video is overlayed. Xv also programs 
the registers on the video board to position, size, and clip 
the video. 

Xv also provides a programming interface that allows an 
application to control the video. The interface provides basic 
control af turning the video on and off, freezing and capturing 
video frames, selecting active video connections, and con- 
trolling video attributes such as brightness, contrast, hue, 
and saturation. 

Collaboration Using Video Images 

As previously mentioned, captured frames of video can be 
used by any of the image-capable components of HP 
M Power. This functionality provides powerful collaboration 
capabilil ies. How many times have you been on the phone 
trying to describe a physical object to someone and wished 
thai they could see the object? For example, consider a 
technician win king with a prototype printed circuit board. 
As frequently happens during early hardware development, 
a few wires are put on Ihe board to fix layout problems. Sup- 
pose the technician is having some problems with the board. 
The technician contacts the design engineer and describes 
Ihe problem. The engineer says the problem sounds like a 
problem that was fixed in an earlier release of the board. 
The technician and the design engineer can try to fix the 
problem over the telephone, and if that doesn't solve the 
problem, eit her the board or the design engineer must make 
a trip to fix the problem. 

If both the technician and the design engineer are equipped 
with workstations running IIP MPowerand live video capa- 
bility, the technician can point a camera at the defective 
board or a specific area of t he board and capture a frame and 
save it to a TIFF file. The TIFF file can then be (hopped into 
the HP SharedX Whiteboard and the engineer and technician 
can share the Whiteboard image. The engineer circles Ihe 
areas where changes were made and shows the technician 
how to make the changes. 

This is a specific example which can be extended to any 
situation in which someone is trying to convey information 
about a physical object. 
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Fig. 2. Client/server architecture and interface points tO the viileu 
hardware and the workstation display. 



Conclusion 

As computer technology and computational power continue 
to progress, the capability of processing video information 
becomes more feasible and less expensive. Video boards are 
now available from third parties that provide similar func- 
tionality to the Videoljve board, with the additional capabil- 
ity of capturing the video data in real time (30 frames per 
second) and saving the digitized video on disk. HP has re- 
leased a software digital video player that plays MPEG en- 
coded video files from disk at up to 30 frames per second 
without additional hardware (see "Digital Video in HP 
MPower." on page 8). 
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Mail Facilities in a Multimedia 
Environment 



Providing a multimedia email facility required that the well-established 
processes of creating, sending, receiving, printing, and replying to email 
messages be maintained and applied to messages containing multimedia 
objects 

by Robert B. Williams. Harry K. Phinney, and Kenneth L. Steege 



The advent of tools and capabilities that allow users to 
manipulate and create multimedia objec ts on a workstation 
mandated the need to make it possible to send these objects 
through electronic mail, or email. The user interface for 
creating, reading, and sending text messages through email 
is well-established. For multimedia email to be effective the 
samp sort of process flow must be in place. For example, 
just as a user can use the more command to view a standard 
text email message, an equivalent facility must be available 
to view a multimedia email message. What this implies is 
lhat the user should not have to be concerned with invoking 
the correct software to deal with a particular media type 
because this should be handled by the mail facility. 

The HP MPower mail facility, which is represented by the 
envelope icon on the HP MPower front panel, provides 
support for sending, replying, viewing, and printing of 
multimedia mail. 

For sending multimedia email. IIP MPower provides two 
approaches: dragging and dropping a file on the envelope 
icon or clic king on the envelope ic on. With the drag-and 
drop method, Ihe user is presented with Hie dialog box 
shown in Fig. la. From this box the user can either send the 
dropped file to its destination by selecting the Send button or 
edit the file by selecting Ihe Edit button. If the Edit button is 
selected, the mail composer (editor) window is displayed 
showing the contents of the file that was dropped on the 
mail icon (see Fig. lb). 

To read mail Ihe user can click on the mail icon and be pre- 
sented with the two windows shown in Fig. 2. The first win- 
dow contains the Standard elm screen and the other contains 
the HP MPower viewer screen. Elm. which is the HP-1 'X* 
screen-oriented electronic mail processing system, provides 
the user interfac e for the user to interact with Ihe HP 
MPower mail system. To edit or create a multimedia mail 
message, the user can access the HP MPower mail editor 
(composer) by selecting Mail Msg from Ihe elm screen. This 
will provide the screen shown in Fig. lb. 

To read or view a mail message, the user would selec t one of 
the messages in the message list and then press Read Msg 
menu item from the elm screen shown in Fig. 2. The selected 
mail message will appear in the IIP MPower viewer window 
for reading 
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Fig. 1. (a) The dialog box thai appears aflnr a mail message is 
dragged and dropped on the front-panel mail icon. Selecting the Send 
button will send the message to its destination, (h) Selecting the Edit 
button produces the mail composer screen. 



HP MPower Mail System Components 

The main components of IIP MPower mail include Ihe 
HP-UX elm mail user agent, a multimedia editor, several shell 
scripts, a standard multimedia file format and supporting 
software, and HP VUE actions and file types. Fig. 3 shows a 
simplified diagram of some of the main HP MPower mail 
components responsible for providing the user interface 
act ions described above. 

With Ihe exception of vuemime, which among other things 
handles the encoding and decoding of multimedia data, the 
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is the MallViewer window. It is the companion window to the Mail window. 

When you choose a tile to read in the Mail window, the message is displayed 
here. You cannot edit the contents of this window. 
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* the Mall and Mail Viewer windows. » 
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Fig. 2. The windows produced by 
jusl (iitking the mail icon. The 
top window contains aim and the 
lower window contains I he HP 
MPower viewer. 



components shown in Fig. 3 that send or receive data re- 
quire no specific knowledge ahoul dealing with multimedia 
data. For example, when a media-rich Tile is sent lo sendmail, 
the file is treated like any other file going onto the network. 
Anolher example is when the composer or viewer needs to 
render a multimedia object (e.g.. play an audio Tile or draw 
an image), the media icon is mapped to the process (or ac- 
tions) capable of handling the particular media object by the 
IIP VUE action database. 

Vuepad. This is an enhanced version of the HP VUE editor. It 
provides two modes of operation in the HP MPower mail 
system: composing (creating a multimedia mail message to 
send) and viewing (reading a multimedia mail message). 
Vuepad is described in detail later in this article. 

HP VUE Action Database. When a particular file type is selected 
the HP VUE action database provides the mechanism for 
invoking the appropriate action associated with that file 
type. For example, when the user double-clicks on an icon 
represeniing an audio file, the HP VUE action database tells 
vuepad thai the audio player should be invoked to play the 
contents of the file. 



MIME. Vuemime, and Metamail. To handle the interchange and 
storage of different types of data, IIP MPower uses an inter- 
net standard known as MIME (Multipurpose Internet Mail 
Extensions). MIME is an extension to the basic interne) mail 
standard RFC 822, which specifies the format for internet 
text messages. MIME defines the format for multipart, multi- 
media mail messages. Vuemime and metamail arc utilities thai 
provide support lo HP MPower for MIME data. Vuemime pro- 
vides a single interface for HP MPower components using 
MIME data, and metamail is a public-domain ulilily (hat we 
modified to act as a MIME filler. In this role metamail decodes 
and flattens MIME messages from non-HP MPower sources 
and encodes messages going to the mail transport agent 
sendmail. Vuemime is the only HP MPower component thai 
communicates directly with metamail. MIME, vuemime. and 
metamail are described hi more detail later in this article. 

Mail User Agents. HP MPower has two mail user agents, elm 
and a shell script called mmsend. Elm is the main user agent, 
providing the usual elm capabilities of viewing, printing, 
saving, or deleting incoming or stored mail, replying or for- 
warding mail, and originating mail. Elm is the standard mail 
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Fig. 3. Some of the main com- 
ponents conttdried in the HP 
MPower mail facility. 



processor lhal is shipped with every IIP workstation. This 
greatly reduces the support load and avoids duplication of 
development effort. L'nfortunately it also put us in the posi- 
tion of offering a keyboard-based mail agent amidst a large 
collection of applications with graphical interfaces. Access 
to elm is through clicking on the mail icon, producing the 
screens shown in Fig. 2. 

( )ne of the obvious changes to elm's normal interaction model 
is the loots used to view and cdil mail. In the IIP MPower 
environment, since we have to deal with mail thai may con- 
lain nontextual items, Ibe multimedia composer (edilor) and 
viewer in vuepad are used to edit and view mail. This is done 
by modifying the user's elmrc (configuration) file so that 
instead of invoking vi or more for editing or viewing a file, HP 
M Power's edilor or viewer are invoked. Most other user CUS- 
lomizalions of elm behavior in the elmrc file are preserved. 

The second mail user agent, mmsend, provides an interface 
for drag and drop mailing of multimedia objects. Dropping a 
file or files on the mail icon causes the software to invoke 
an HP VUE action that indirectly calls the mmsend shell 
script. Mmsend drives the processes that are responsible for 
displaying and interacting with the screens shown in Pig. 1. 
The mmsend script also invokes the processes that convert, 
multimedia files into MIME formal. When the user selects 
the Send button from the mail dialog box shown in Fig. 1, 
mmsend invokes the mail transfer agent sendmail to dispatch 
the message over the network. 

Mail Transfer Agent. The primary mail transfer agent in the 
current version of HP MPower is sendmail, the HP-UX facility 
for sending mail over the internet. Although there are gate- 
ways from sendmail SMTP (Simple Mail Transport Protocol) 
to X.-IOil and < IpenMail. these gateways are not supported 
because they have not been enhanced to understand MIME 
on the SMTP (oiilbound) side. 



Instant ignition systems (see page 17) usually do not have 
sendmail enabled. To overcome this the HP MPower installa- 
tion scripts set up a default sendmail.fc and alias database. 
This is only done if sendmail is not already enabled. It does 
not address sendmail connectivity issues in complex or re- 
stricted environments. Ideally, sendmail would be turned off 
on miniclient systems because the mail agent runs on the 
server with the rest of HP VUE. 

Printing. Multimedia printing involves decomposing the MIME 
formatted file into its parts and invoking the HP MPower 
print action (HP SharedPrint) on each of the parts. IIP 
SharedPrint is described in the article on page 44. Invoking 
IIP SharedPrint for mail is handled by the shell script mmprint. 

Several types of multimedia cannot be printed (e.g.. audio 
files). This is handled by a print action for the unprintable 
file lhal maps to the special action NONE. 

Since printing actions happen on the client (HP SharedPrini 
forces this), vuemime and its database mimetvpes must exist on 
the client as well as ihe server. This has implications for 
installations adding multimedia types. 

Multimedia Editor 

An important aspect of a multimedia mail facility is the ability 
to compose and view documents containing both text and 
nontextual items, hi the IIP MPower environment this abil- 
ity is provided by a specially evolved version of the IIP VUE 
text editor, vuepad. t All of Ihe multimedia editing and view- 
ing facilities av ailable in IIP MPower are built on Litis new 
version of vuepad. 

The development of this component was constrained by 
many different factors. The schedule was set to allow the 

t Unless staled otherwise releiences to vuepad in the rest of this article will he returring tn the 
new version ol Ihe program 
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introduction of the product to c oincide with I lie release of 
new workstation computers. This ensured good public expo- 
sure for the product, but limited the amount of time and the 
number of engineers available for product development. The 
schedule and staffing level provided a strong motivation for 
using the functionality of existing products rather than 
wholesale development of new components. 

Vuepad Modes. The vuepad program provides two modes. One 
is the HI' MI'ower mail composer (mentioned previously) 
for creating and editing multimedia documents. The other 
mode is the HI* MPower mail viewer (also mentioned pre- 
viously) for viewing or listening to multimedia documents. 
The viewer is simply a read-only version of the composer. 
These facilities are accessible from the HP MPower mail 
icon or the HP VUE panel edit icon. The activation of either 
of t hese two modes is determined by the arguments passed 
to the vuepad program when it is invoked from the rnmpad 
script shown in Fig. 3. 

The HP MPower mail composer takes files created by the 
various media editing tools such as the HP SharedX White- 
hoard or the audio editor and allows the user to incorporate 
the files generated by these tools into a document contain- 
ing text. The final output of a message created by the com- 
poser Is in a formal compatible with the MIME standard. This 
approach required no modifications to any of the media edit- 
ing tools and no changes to the core email application (elm). 
Use of the MIME message format helps provide some inter- 
operability with other mail systems and gives us access to 
an already well-documented and carefully defined structure 
for messages. 

Fig. 1 shows that the vuepad editor provides the composer and 
viewer with a visually appealing "iconic" view of nontextual 
data The vuepad editor ensures that a user's normal editing 
actions function as the user expects in the presence of non- 
textual items. It also ensures that the operations available 
for manipulating nontextual items are clearly visible. 

Modifications to Vuepad. The required modifications to the old 
vuepad editor included adding the ability to invoke a filtering 
program for reading and writing multimedia data. The choice 
to do this filtering in a separate program was primarily driven 
by the need to develop the filtering functionality in parallel 
with the enhanced editor, and a desire to use different de- 
velopment programming languages for the editor and filter. 

The filter is the vuemime program mentioned earlier. When 
vuepad is reading a multimedia file, vuemime strips out the 
media data, writing each media object to a separate t empo- 
rary file. The media data is replaced within the original data 
stream by a special character sequence indicating that a 
media object existed in that location. This character se- 
quence, known as a tag. contains the name of the temporary 
file that holds the media data. This file is used by vuepad and 
the HP VUE file-typing facilities to determine the graphical 
icon to display in place of the media object. When vuepad 
writes to a multimedia file, vuemime inspects the file for any 
tags and replaces the tags with the actual media data and 
the necessary MIME header information. 

It was necessary to augment or override some of the inter- 
nal functions of the OSF/Motif text widget that vuepad is 
based on. Before the widget draws a line of text, vuepad 
checks to see if the text corresponds to part of a media icon. 



If it does, then vuepad draws the necessary portion of the 
icon. If the text does not contain part of an icon, then the 
text widget is allowed to render the whole line of text. 
Whenever the widget writes or reads data to or from either 
the OSF/Motif clipboard or the X primary selection window 
(a clipboard that can hold one item at a time), vuepad runs 
the data through the vuemime filter program to reinsert or 
strip any embedded media data as required. When the user 
selects a portion of text for an editing operation, vuepad tracks 
the selected region to provide meaningful highlighting ofany 
selected media icons. Vuepad also observes all deletions and 
additions to the document to accurately track the position 
of the media objects within the document. Special care is 
also taken during the spell checking and formatting opera- 
tions. The spell checking code must exclude the rather cryp- 
tic media tag data from the text sent to the spell checking 
program, and the formatting code has to do its work while 
preserving the relative locations of the media icons. 

Compatibility. The behavior of vuepad is controlled by X 
Window System resources and command line options that 
allow vuepad to behave Identically to the previous nonmedia- 
enhanced version of the IIP VUE editor. The HP VUE file 
typingt and action database mechanisms were used to 
speed development and to provide consistency with HP 
VUE's file manager appearance. The HP VUE action data- 
base provides a simple means for invoicing an appropriate 
action associated with any particular file type. Use of the 
action database in vuepad ensures consistency with the de- 
fault action accessed from t he file manager for a particular 
file type. 

Composer Features. Tito IIP MPower multimedia composer 
presents a flat, scrollable view of a document. This allows 
the user to access any and all document pails rapidly with 
no enforced sequential ordering. The media objects are em- 
bedded in the document, that is, the actual media data is 
copied into the resulting file rather than having links main- 
tained to the original data. This ensures that the recipient of 
a message not only has immediate access to the data, but 
also results in larger messages and freezes the data at the 
time of composition. The media objects can be embedded at 
any location within the document, providing significantly 
more flexibility than the "attachment" model used by many 
mailers. The attachment model maintains links to other 
parts of a document. 

To incorporate a media object into a document being com- 
posed, the user can either use the Include dialog facility of 
vuepad or drag the object from a file manager view and drop 
it on the composer's window. If the user wishes to create a 
new media object while composing a message, the appropri- 
ate editing tool (e.g.. the audio editor or the image editor) 
must be used to create the object within that editor. After 
the media object is created and saved in the file system, vue- 
pad's Include dialog or drag and drop facilities can be used to 
include the new object in the message being composed. 

As shown in Fig. 1, the composer displays icons in place of 
;dl nontextual portions of the document. This results in a 
reasonably attractive appearance and good user recognition 
because of the similarity with the IIP VUE file manager 

t The HP VUE tile typing mechanism provides ihe capability to define classes ol tiles, for 
example, it can define all tiles ending wiUi til to be ot class TIFF. 
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ic onic view. The user can eilher double-click with the mouse, 
or press the Return key to activate the currently selected 
icon. This provides a simple and quick means of viewing or 
playing the media item and allows easy access from the key- 
board for those users who prefer not to move their hands l" 
the mouse. 

The composer also provides an Actions menu item which is 
sensitive whenever a single media item is selected. This 
menu contains two items. The Brst item is Open, which dupli- 
cates the functionality of double-clicking on the selected 
icon. The second item is Save As. which allows the user to 
save the selected media object to another file separately, 
with no MIME structure. The Save As action is also the de- 
fault "open" action of the unknown data type. The unknown 
data type allows users to pass arbitrary binary data through 
the mail system undisturbed. 

The current implementation of the composer does have 
some limitations, but a foundation has been built upon 
which to improve and add features to the current version. 

Multimedia Data Extensions 

As mentioned previously. HP MPower supports the inter- 
change and storage of several different types of multimedia 
data contained in a single message or a file via a format con- 
forming to an extension to internet mail known as MIME 
(Multipurpose Internet Mail Extensions). This multipart, 
multimedia support is implemented in HP MPower by two 
utilities: metamail and vuemime. Metamail is a public-domain, 
sample implementation of a full-featured MIME agent. Vue- 
mime is a MIME niter that was created specifically for HP 
MPower and HP VI IE to simplify generation and manipula- 
tion of multipart, multimedia data from the various IIP 
MPower components. 

We selected MIME for its strong support within the internet 
mail community, and we found it to be also useful outside 
the mail domain. The HP MPower environment recognizes 
files structured in c ompliance with the MIME specifications 
and will deal with them transparently for editing and printing. 
The composer allows the user to insert nontextual objects 
into any document being edited, and the resulting file will be 
saved in MIME format. The MIME message formal is also 
used for cut and paste operations between editing windows. 
This allows the user to treat editing of mixed-media data in 
the same manner as plain text. Unfortunately, the mail com- 
poser is currently the only application that understands 
MIME data in cut and paste operations. 

This section first provides some background on MIME, 
describes metamail in the context of IIP MPower, and then 
discusses vuemime in some detail. 

MIME Background. Since 19R2 the standards that form the 
basis for internet mail have been defined by RFC 822 anil the 
SMTP (Simple Mail Transport Protocol ) defined by RFC 821.1 
RFC 822 was intended to spec ify a format for text messages 
and. as such, did not explicitly allow for inclusion of multi- 
media messages such as audio or image data. In particular, 
RF( ' 822 defines a message as consisting of two parts: a 
header and a body. The header consists of a series of specific 

field names and field values followed by a blank line that 

t Each internet standard is defined by one or more standards each known as a Request lor 
Comment, or HFC 



marks the end of the header and the beginning of the body. 
The body is restricted to relatively short lines ( 1000 charac- 
ters) of seven-bit ASCII characters which cannot exceed a 
certain length. L'sers who wish to include nontextual data 
have to convert the data to seven-bit .ASCII before submitting 
the data to their mail user agent or mail program. 

RFC 1049 attempted to rectify some of the deficiencies of 
RFC 822 by defining a header field and a content type that 
marks the entire message body as being a certain type of data 
(e.g., text, audio, video, etc.). In the absence of a content- 
type field, the body was assumed to be U.S. ASCII text, as 
before. Although RFC 1049 has been used by several imple- 
mentations, it is not without problems. The most severe 
problem is its total lack of support for multipart mail. RFC 
1049 allows a message body to be specified as containing 
something other than text, but only one such thing. 

RFC 1341. or MIME, generalizes and extends RFC 1049 in 
several ways. Most important, it defines a new content type 
called multipart, which can be used to encapsulate several 
body parts within a single RFC 822 message body. It also 
goes far beyond RFC 1049 in explicitly describing the set of 
allowable content types by defining a subtype mechanism 
for content types that includes provisions for addressing 
standardized encoding of non-ASCII character sets. It should 
be noted that RFC 1341 is an extension to, rather than a 
revision of RFC 822 in that it defines these new features 
(including text of unlimited line and overall length, charac- 
ters sets other than ASCII, and multifont messages) within 
the confines of RFC 822. 

The new header fields and content types defined in the 
MIME extension are described on the next page. 

Metamail. Metamail is a public-domain, sample implementation 
of a MIME agent that was designed to function as a back 
end for an existing mail user agent. It can be incorporated 
into virtually any mail reading (or bulletin board) program 
(e.g., xmail, xmh, elm, etc.), enabling it to become a multimedia 
reading interface. Metamail knows how to parse a structured 
MIME message, Batten any hierarchy of nested messages, 
decode the various parts, and optionally, dispatch the appro- 
priate handlers or viewers for the different parts. The- com- 
mands used to dispatch the handler or \iewer for each con- 
tent type are specified in one or more mailcap (configural ion ) 
files, which allow a great deal of flexibility in adding and con- 
figuring handlers. As a viewer, metamail can be thought of as a 
multimedia counterpart to the ASCII paging tool, more, exc ept 
thai il enlists t he aid of additional handlers and viewers when 
paging through a message in a lineal - fashion. 

In IIP MPower we needed more flexibility when composing, 
viewing, printing, and sending mail so we did not incorpo- 
rate metamail directly in our mail user agent (elm). Instead, we 
use the enhanced version of vuepad described above as our 
mail viewer and composer and we delegate metamail to the 
role of a MIME filler or preprocessor and postprocessor, In 
this role, metamail serves primarily to simplify the digestion 
and generation of MIME compliant messages by other IIP 
MPower components. Specifically, metamail is used to flatten 
potential message hierarchies and to encode and decode 
each message part according to its encoding scheme, t )n the 
input side (mail receiving), for example, if we receive a 
MIME message from a non-HP MPower sender, we pass il to 
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MIME Header Fields 



The MIME extension |RF 1341) 10 the basic internei mail standard HFC 822 created 
the following new header fields: 

• MIME Version This field is used to specify a version number that declares a 
message conformant with the MIME standard 

• Content Type This field is used to specify the type and subtype of data in the body 
of a message and to specify the complete encoding of such data 

• Content Transfer Encoding This field is used to specify auxiliary encoding applied 
to data to allow it to pass through mail transports having data or character set 
limitations 

• Content Identifier and Content Description These fields are used to further describe 
data in the body of the message 

Content Types 

MIME enumerates precisely seven valid content types and requires that any addi- 
tions to this set be specified in a new. similarly formal document This restriction 
is a major change from RFC 1 043, which allowed for much freer definition of new 
content types. Instead, the new mechanism for extensions is to define new sub- 
types of established content types. In general, implernentors are required to regis- 
ter new subtypes with the Internet Assigned Numbers Authority (IANAI to avoid 
name conflicts |An exception is private subtypes beginning with the letter X, 
which can be used freely and without registration I 

The seven defined content type values are: 

• Text. This is the default content type The default subtype is plain text. This 
content type has a charset attribute that has the default value us-ascii. 

• Image This content type is for still images. Subtypes are image format names 
leg . image/gif and image/ipeg) 

• Audio This content type is for audio information Subtypes are audio format 
names For example, audio/basic denotes single channel 8000-Hz u.-law audio 
data 

• Video. This content type is for video frames Subtypes correspond to video format 
names such as video/mpeg. 

• Message. This content type is used to encapsulate an entire RFC 822 format 
message For example, it can be used in forwarding or rejecting mail The stan- 
dard defines two subtypes of message: message/partial, which can be used to 
break a large message into several pieces (or transport so that they can be put 
back together automatically on the other end, and message/external-body, which 
can be used to pass a very large message body by reference, rather than including 
its entire contents 

It should be noted that a message with a message content type can contain a 
message that has its own. different content-type field, meaning that the message 
structure can be recursive. 

Multipart This content type is used to pack several parts, of possibly differing 
types and subtypes, into a single RFC 822 message body The content-type field 



specifying a multipart type also includes a delimiter, which is used to separate 
each consecutive body pan Each body part is itself structured more or less as an 
RFC 822 message in miniature, possibly containing its own content-type field to 
describe its type. Subtypes of multipart types are specifically required to have the 
same syntax as the basic multipart type, guaranteeing that all implementations 
can successfully break a multipart message into its component parts. An expected 
use of multipart subtypes is to add further structure to the parts and to permit a 
more integrated structure of multipart messages among cooperating user agents 
• Application This content type is for most other kinds of data that do not fit into 
any of the above categories, such as list servers, mail-based information servers, 
and PostScript.™ 

A separate part of the content-type header field can be used to convey supple- 
mental information that may be either optional or required, depending on ihe 
content type. Such parameters are given in keyword = value format, and are used, 
for example, to convey information about character sets for text objects. Thus, the 
default message type for internet mail can be given a MIME content type of: 

Content-type: text/plain; charset=us-ascii 
Content Transfer Encoding 

If internet mail transport (SMTP, as described by RFC 821 ) is ever upgraded to 
permit arbitrary binary data of unlimited line length in message bodies, the issue 
of encoding a message for transport will go away However, even those who 
advocate such changes to SMTP generally recognize that they will be slow in 
coming. In the interim, there is wide perception that a standard mechanism for 
encoding arbitrary binary data for mail transport is needed 

The content transfer encoding header field can be used to specify the encoding 
technique used to render binary data in short lines of seven-bit data. After much 
debate, the working group settled on two encodings, which may be used inter- 
changeably One of them, the base-64 encoding, encodes each three bytes of 
binary data as four bytes of 7-bit data, using a base-64 alphabet selected for 
maximum portability across SMTP implementations, including ASCII to EBCDIC 
gateways. The other encoding scheme, quoted-printable. is a less efficient repre- 
sentation that preserves nearly all 7-bit ASCII characters as themselves. It is 
expected that base-64 will be preferred for genuine binary data, while quoted- 
pnntable will be preferred for data that is largely U S ASCII, but has scattered 
non-ASCII characters within it In particular, this may be the preferred encoding for 
textual email in the national-use variants of ASCII, ISO 8859-X. 

If the content transfer encoding field appears in the RFC B22 message header, it 
refers to the body of the message If it appears in the header area of one part of a 
multipart message, it refers to the body area of that part only. The content transfer 
encoding field is prohibited when the content-type field has a value of multipart or 
message. This is necessary to prevent nested encodings. 



metamail. which filters it by flattening any nested message 
hierarchies and decoding each message pail. The result is a 
Simplified MIME template that can be easily dealt with by 
other HP MPower components. On the output side (mail 
sending) metamail is used mainly to encode message parts for 
handling by the .SMTP transport used by our mail transport 
agent sendmail. While we can handle nested messages on the 
input side, we only generate flat, single-level messages on 
the output side. 

The official metamail documentation and software, including 
a draft of RFC 1341. can be found in the pub/nsb directory on 
thumper.bellcore.com. 

Vuemime. In HP MPower, interaction with MIME messages is 
not the sole domain of the mail user agent (elm) and its 
viewer and composer (vuepad). Since MIME Ls used as the 
storage format for all multipart, multimedia data, printing 



and sending MIME data as well as composition and viewing 
have to be performed independently of elm. Printing and 
sending, for example, can be done by simply dropping a 
MIME file on the HP VUE front-panel printer or mail icons 
without invoking elm or vuepad. 

Vuemime was created specifically for HP MPower components 
to provide a single interface to MIME data and. as such, vue- 
mime is the only HP MPower component that directly enlists 
the services of metamail. Essentially vuemime can be viewed as 
a higher-level MIME filter which, in addition to providing the 
type of filtering performed by metamail. provides intermediate 
formatting that is easily digested by various HP MPower 
components. What has resulted, after analysis of the needs 
of various HP MPower components, is essentially five levels 
of formatted data which can be viewed as stages in a file's 
morphosis from raw data (level 0) into a fully formatted 
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Fig. 4. Processing an incoming 
message, (a) Level-:) file formal 
and tin' actions of vuemime Co move 
from a MIMIC formal to ;i lcvel-2 
file formal (i>) Level-2 file format 

and Lhe actions performed by 
vuemime (0 transform the data to 
alevel-1 representation, (r) 
Level- 1 file format representation 
imd lhe actions taken by vuepad to 
display textual and nontextual 
parts of the message. 



MIME message ready to he handed off to the SMTP mail 
transport. 

Fig. 4 shows the steps involved in transforming an Incoming 
message in MIME format (level 3) through the various levels 
of formatted data to a tagged (level 1 } format. For an outgo- 
ing message, vuemime will lake a lagged message and gener- 
ate a sell-contained MIME message thai ran he passed to 
the mail transfer agent 

The five levels of formal ted dala shown in Fig. 4 are denned 
as follows: 



• Level 0. This is raw data consisting of ASCII text and non- 
textual information such as image, audio, and video data. 

• Level 1. Data at this level, which is used by vuepad and the 
mmpnnt action, is in a special lagged formal that contains only 
ASCII text, summarized mail heading information, and spe- 
cial tag lines representing multimedia objects. The tag lines 
indicate the multimedia type and a path to a lile containing 
the raw data. See lhe level-1 lile representation in Fig. 4c. 

• Level 2. This is an external-body file format The formal at 
this level is very similar to level 1 except that MIME header 
and Control lines have been added to make it fully MIME 
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compliant. All multimedia objects are still external (and 
raw) but are now identified by Content-type: <message>/ 
<external-body> and Content-type: <typc>/<subtype> lines. 
See the level-2 file representation in Fig. 4b. 

HP MPower does nol currently send messages in level-2 file 
format, but this level could be useful in at least two situa- 
tions. First, level-2 format could greatly reduce the size of a 
message by not sending the actual contents of something 
like a video clip. In this case, the video informal ion is not 
sent until and unless the receiver wishes to view Ihe video. 
The other important use of level-2 file format, is to provide a 
"hot link" to the current version of some data. For instance, 
a message might contain an external-body reference to 
some dala that is updated hourly. The receiver of the mes- 
sage would see valid data at the time the message is read, 
instead of Ihe data as of Ihe time the message was sent. 

• Level 3. This is a MIME file. All references to external multi- 
media data files are replaced by encoded data. See the 
level-3 file representation in Fig. 4a. 

• Level 4. This is a MIME file with an outgoing mail address 
and header information (from Ihe mail user agent) prepended 
to it. At this level the data file is ready to be transported to 
the network services. 

Vuemime accepts command line options to transform data in 
either direction and between any levels from 0 to 3. Level 4 is 
generated solely by the mail user agent (mmsend) for outgoing 
mail. The HP MPower component (vuepad) simply indicates 
to vuemime on the command line the level of the file being 
transformed and the level to which it is to be formatted. 

Vuemime generates only base-64 encoded data when going 
from a level-2 (or lower-level) file to a level-3 (MIME ) file 
even though it can accept other types of encoded data when 
going from a level-3 file to a lower level. Also, vuemime only 
generates flat multipart and mixed level-2 and level-3 mes- 
sages even though it can accept and digest (via metamail) 
nested level-3 messages generated by a non-HP MPower 
MIME system. 

Mimetypes. Transformation to and from raw data by vuemime is 
controlled by a file called mimetypes. The mimetypes file is a 
cross between metamail's mailcap files and HP VUE's file-type 
definition files. Table 1 shows the contents of the mimetypes 
file supplied with IIP MPower 1.0. 

Vuemime uses the data in the first column to map level-0 (raw 
data) files to the content type for files that are being trans- 
formed to a higher level. The third colunui is the content-type 
value inserted in files of level 1 and above. For level-1 files 
and above that are being transformed to level-0 files, the 
column 2 entry associated with a particular content type is 
used to determine the file name extension to be applied to 
the new r raw data file. 

Conclusion 

Our multimedia email project is an example of a highly 
leveraged effort that combined existing blocks of function- 
ality, some modifications, and new "glue" to meet a market 
need quickly. 



Table I 

Contents of the HP MPower 
Search Pattern File Extension 



Mimetypes File 
Content-Type Value 



for Raw Data 


for New Raw 




Files 


Data Files 




.*Yxwd 


%s.xwd 


image/x-xwd 


Axd 


%s.xd 


image/x-xwd 


.'Uif 


%s.tif 


image/x-tiff 


.•Ytiff 


%s.tiff 


image/x-tiff 


,*\.eps 


%s.eps 


image/x-eps 


Apcl 


%s.pcl 


image/x-pcl 


Agif 


%s.git 


image/gif 


-*Vjpg 


%s.jpg 


image/jpeg 


•"Vjpeg 


%s.jpeg 


image/jpeg 


."\.pm 


%s.pm 


image/x-xpm 


."Vxpm 


%s.xpm 


image/x-xpm 


Abm 


%s.bm 


image/x-xbitmap 


Axbm 


%s.xbm 


image/x-xbitmap 


Abmf 


%s.bmf 


image/x-bmf 


Aps 


%s.ps 


application/PostScript 


Atxt 


%s.txt 


text/plain 


Aau 


%s.au 


audio/basic 


AI16 


%s.H6 


audio/x-Linear16 


.*\.I8 


%s.l8 


audio/x-Linear8 


Alo8 


%s.lo8 


audio/x-Linear-80flset 


*\.wav 


%s.wav 


audio/x-microsoft-RIFF 


Asnd 


%s.snd 


audio/x-NeXT 


Au 


%s.u 


audio/x-MuLaw 


Aal 


%s.al 


audio/x-ALaw 


AZ 


%s.Z 


application/x-compress 


Atar 


%s.tar 


application/x-tar 


Aunk 


%s.unk 


application/octet-stream 
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A Fast and Intuitive Online Help 
System 



The HP Help System provides application developers with the tools to 
create and integrate rich online help information into their OSF/Motif- 
based applications. 

by Michael R. Wilson. Lori A. Cook, and Steven P. Hiebert 



With the grow ing complexity of today's UNIX*-operating- 
system applications, and the desire to improve usability, 
media-rich information is becoming more pervasive in 
today's computing environments. Users expect some base 
level of online help to be provided from within the applica- 
tions they are using. They expect online information to be 
intuitive and graphical, with growing expectations of direct 
audio and video support and interactive capabilities. 

The HP Help System is a good start towards providing multi- 
media online information that is both fast and intuitive. It has 
become the standard online help system within HP and is 
used extensively by the HP VUE and HP MPower products 
and many other OSF/Motif-based products. 

Background 

The current HP Help Developer's Kit is the second attempt by 
the HP Vl'K program to deliver an application help system 
for everyone. The first version, HP Vuehelp 2.0, white satisfy- 
ing some of the IIP VUE requirements as an application help 
system, failed to meet application developers' requirements 
for features, performance, and ease of integration. 

One of the design goals for the IIP Help System was to de- 
liver a complete solution to developers for creating, inte- 
grating, and shipping rich online information with their OSF/ 
Motif-based application, while keeping its presence (system 
resource use) to a minimum. There is a very fine line between 
providing the rich set of features that our customers require 
and maintaining our performance objectives. In 95% of the 
cases in which the issue of features versus performance 
came up. performance won. 

Based on the knowledge and insight our team gained in doing 
Ihi' first version of the HP Help System, and a willingness to 
make radical changes in our second release, we basically 
started from scratch. We knew that our next-generation help 
system needed to provide a competitive set of base features 
and functionality that developers require, while producing 
little or no end-user-visible performance degradation to the 
hosting application. 

The Help Developer's Kit 

The IIP Help Developer's Kit is a complete system for devel- 
oping online help for any < >Sr7Molif-hased application. It 
allows authors to write online help that Includes graphics 
and lexl formatting, hyperlinks, and communication with 
the application. It provides a programmer's toolkit allowing 
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Fig. 1. Ht'lp dialog widget. 

developers to integrate this rich online help information into 
their client application. The help dialog widget (Fig. 1) 
serves as the main display window for the IIP Help System. 
A second, lighter-weight help widget (quick help dialog) is 
also available in the toolkit. 

Following is a list of the components supported in the 
developer's kit: 
For Authors 

The HP HelpTag markup language. This is a set of tags 
used in text files to mark organization and content of on 
line help information. HP HelpTag is based on SGML 
(Standard Generalized Markup language). 
The HP I lelpTag software. This is a set of software tools 
for converting the authored HP HelpTag files into run-time 
help files that contain the text for the help messages 
displayed in the help widgets. 

The HelpView application. This is a program that allows 
an author to test a newly developed online help facility. 
For Programmers 
The Xvh programming library. This library provides an 
application programming interlace for integrating help 
windows into an application. 
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A demonstration program. This is a simple example thai 
shows how to integrate the HP Help System Into an OSFV 
Motif applieation. 

General Packaging Architecture 

An online help system needs lo feel like ii is pail of Ihe host 
application to the end user, not an appendage hanging off to 
Ihe side. Fur developers lo leverage a tJiird-party help system, 
it must he delivered in such a way as to provide easy and 
seamless integration into (heir application. Furthermore, the 
effort and overhead of integrating and redistributing this 
help system along with their application must be minimal, 
while at the same time meeting the application's and end- 
user's requirements for help. Users should feel as if Ihey 
have never left Ihe application while getting help. 

During our initial prototyping of the current HI' Help System, 
we kept stumbling on Ihe same Iwo key Issues: performance 
(how to make the system light and fast ) and packaging (how 
to make it easy to integrate into any OSF/Motif-based appli- 
cation and redistribute with that application). Our initial 
help system suffered greatly in both of these areas. HI' Vue- 
help 2.0 was server-based, large, slow, and dependent on the 
IIP VUE desktop, Any application using our help services 
had to run within the HP VI E desktop environment. 

We addressed these two issues with our current release and 
ended up with a very different package. To fix Ihe perfor- 
mance problems of slow startup limes and heavy server- 
based implementation, we started copying funclionalily from 
the help server into the client via a linked-in help library. 
While prototyping this architecture, we quickly realized that 
we were duplicating services. However, we were also get- 
ting much better performance from the new client code. At 
that point we realized that if we moved everything to a help 
library we could fix our two biggest problems: performance 
and packaging. 

By moving to a help library and removing our hard-wired 
dependencies on the IIP VI 'E desktop and by bundling our 
product with I IP's I 'ser Environment Developer's Kit, we 
cleaned up our previous dependency problems with HP 
VUE. Now developers can embed help directly into their 
application and ship a single executable that includes both. 
Developers only have to link their OSF/Motif application 
with the HP Help System library and they are ready to go. 
All dependencies on external system and desktop services 
have been removed. Fig. 2 shows an overview of our old and 
new help system architectures. 

Following are some of the advantages we gained by moving 
from our initial IIP Vuehelp 2.0 server-based implementation 
to an embedded client-side architecture. 
1 Integration Advantages: 

OSF/Motif-based application program interface (simple to 

use for developers familiar with OSF/Motif) 
3 Complete application control over the help system dialog 

management including creation, destruction, caching, and 

reuse 

: Smooth transition into the help system via consistent 
resource settings between the application and the help 
system (e.g., same fonts and color scheme ami quic k 
response times) 
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Fig. 2. Two different approaches In integrating online help into an 
application. Client side embedded implementation using HP Vl.'E 
-').(! help, (b) Help server implementation using IIP VI. K help. Our 
initial prototypes revealed that Ihe iJienl side embedded solution is 
better in terms of performance (rendering lime) and memory use. 

Immediate support for a tightly coupled application-to- 
help system environment (e.g., application-defined and 
processed help controls such as hypertext links) 
Application-specific customization of the help system. 

• Packaging Advantages: 

Eliminates installation and version problems (Since appli- 
cations are not sharing the help services, the contention 
between older or newer software versions does not exist.) 
Eliminates distribution problems. (The help system is 
linked directly into the host application, tested and 
shipped as one executable. ) 

• Performance Advantages: 

Requires less overall system resources (RAM and disk) for 
a single application using the help services 
Provides much faster initial response lime when displaying 
help requests. 

Integration Concepts, Practices, and Mechanisms 

As mentioned in the previous section, the run-time help 
facility is made up of a collection of help dialog widgets and 
files containing online help information. The help widgets 
are linked directly into the client application via Ihe help 
library libXvh.a* and instantiated by the client to display help 
information. While ihe help dialogs serve only as vehicles 
for displaying online help information, standard OSF/Motif, 
Xlib, and X toolkit (Xl) services provide the glue lo integrate 
the dialogs into Ihe applicalion. 

The online help files in the HP Help System are called help 
volumes. These volumes contain Ihe text for the help lopics 
that are displayed in the dialog widgets. The following files, 
or volumes are used by the HP Help System: 

• volume.hv. This is the master help volume file accessed by the 
HP Help System when a user makes a request for help infor- 
mation. Information slored in this file is used lo access the 
actual help topics stored in the help topic (.ht) files. 

• volume.hvk. This is a keyword index file for the master help 
volume. 

• volumeNN.ht. These lire the help topic files, where NN repre- 
sents file numbers (00. 01, 02 ... ). If there are no chapter 
elements in a help volume, only a single topic file (e.g., 
volumeOO.ht) will exist. These are Ihe files containing the help 
text. 

The relationship between these files is shown in Fig. 3. 
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Fig. 3. The HP help file system. 

There are two levels of integration with respect to the HP 
Help System: integrating help into an application and inte- 
grating a help-smart application into an HP VUE or HP 
M Power desktop environment. 

Integrating Help into an OSF/Motif Application 

Developers have many degrees of freedom with respect to 
how much or how little help capability they include in an 
application. If an application and its help information have 
very loose ties, there may be only a handful of topics that 
the application is able lo display directly. In contrast, the 
application could provide specific help for nearly every ob- 
ject and task in the application. This requires more work, 
but it provides potentially greater benefits to the end user. 

Help Dialogs. Two help widgets are Supported in the help 
library: quick help dialog and general help dialog. They both 
support the same text, hypertext, and graphics display capa- 
bilities, bui differ with respect to the remainder of the user 
interface. The quick help dialog (Fig. 4 ) is a very simple help 
dialog intended for displaying small blocks of text to the 
user. Quick help dialog is best used for handling things like 
error messages, version information, and object and item 
definitions. 

The general help dialog, which is the most commonly used 
help dialog, has a few more user interface features than the 
quick help dialog widget. Most notably, the Topic Hierarchy list 
(see Fig. 1 ), which appears just above the help text display 
area, indicates the location of the current topic in the help 
topic hierarchy. The general help dialog also provides vari- 
ous navigational aids to assist the user in moving about the 
online help information space. 

Standard Xt Paradigm. The programmer interacts with the help 
dialogs in the same manner as any other OSF/Motif widgets 
used by the application. The two types of help dialogs are 
defined by the following two widget classes: 
• XvhQuickHelpDialogWidgetClass (for quick-help dialog) 



• XvhHeipDialogWidgetClass ( for general-help dialog). 

Nearly every attribute of the help windows including the 
volume name and topic identifier are manipulated as widget 
resources. For instance, to display a new topic, an XtSetValuesO 
call is made to set the volume, location identifier, and help 
type resources. 

Creating Help Entry Points 

Each help topic that can be displayed directly as the result 
of a help request is called an entry point That is. if there is 
at least one way to get directly from the application to a 
help topic, then that help topic is an entry point into help. 
Help menus and buttons in the application are the basic help 
entry points for an application. The types of help requests 
that provide entry points into the HP Help System are 
contextual help and item help. 

Contextual Help. Contextual help provides help information 
about the item on which the selection cursor is positioned. 
Contextual help information provides users with Information 
about a specific item as it is currently used. The information 
provided is specific to the meaning of the item in its current 
state. For example, suppose a user is running an application 
that uses an options widget that has four options. If the user 
requests information on the widget while it has option 1 
selected, the user will get help information on the option 
widget in the context of its option 1 setting. 

A selection cursor, which is a visual cue, enables users to 
indicate with the keyboard the choice with which they want 
to interact. It is typically represented by highlighting the 
choice with an outline box. 

The OSF/Motif user interface toolkit, through its help call- 
back mechanism, provides direct support for contextual help 
entry points. When a valid help callback is added to a wid- 
get, and the user presses the help key (F1 ) while that widget 
has the current keyboard focus (e.g., selection cursor), the 
widgets help callback is automatically executed. 

From within the help callback, the application has the op- 
portunity to display some help topic based on the selected 

Help On Help 

I Using the HP Help System 

Welcome to the HP Help System. To learn about using help 
windows, choose one ol the fallowing hyperlinks: 

• Using Hyperllnl 

• Browsing Help Topics 

• Using the Keyword Index 

• Printing Help Topics 

• Revisiting Topics (History) 

To choose a hyperlink: 

Any underlined text you see within a help window is a 

OK Print 



Fig. i. Quick help dialog box, 
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widgel, or the application could dynamically construct some 
help information based on the current context of the selected 
item. 1 - 

Any level of granularity can he applied when adding help 
callbacks to an application's user interface components. 
They can be added to all the widgets and gadgets within the 
application dialogs, the top-level windows for each of the 
dialogs, or any c ombination in between. 

If the user selects F1 help with the selection cursor over a 
widget or gadget that has no help callback attached to it, the 
OSF/Motif help callback mechanism has a fallback mecha- 
nism for providing more general help. The help callback 
mechanism will jump to the nearest ancestor that has a help 
callback assigned and invoke that callback. The theory is that 
if there is no specific help on that widget or gadget, then it is 
better to provide more general help than none at all. Appli- 
cation developers are responsible for adding their own help 
callbacks to the user interface components in their applica- 
tion. OSF/Motif sets these callbacks tu NULL by default. 

Item Help. Item help allows users to get help on a particular 
control (e.g., button, menu, or window) by selecting the item 
with the pointer. Item help information should describe the 
purpose of the item for which help is requested and should 
I ell users how to interact with that. item. An item help re- 
quest does not provide context sensitive information like the 
Current state of the selected item. 

Item help is usually accessed via an application's Help menu 
under the On Item menu selection. Once selected, I he cursor 
is replaced with a question mark cursor. The user can then 
select the item of interest. 

The HP Help System API utility function, XvhReturnSelected- 
Widgetldl) assists developers in providing item help within their 
application. This function provides an interface for selection 
of a component within an application. XvhReturnSelectedWidget- 
ld(l returns the widget identifier for any widget in the user 
interface that the user has selected via the pointer. 

At any point while the question mark cursor is displayed the 
user can select the escape key (ESC) to abort the function call. 
If the user selects any item outside the current application 
windows the proper error value will be returned. 

Once XvhReturnSelectedWidgetldO returns the selected widget 
identifier, the application can invoke the help callback on 
the identified widget or gadget to process the selected item. 
From the help callback the application can display some help 
topic based on the selected widget or dynamically construct 
some help information based on the current selected item. 

Integrating a Help-Smart Application 

There are no restrictions regarding where run-time help files 
are installed. However, a suggested practice is to package a 
help volume in a separately installable file set so that the 
system administrator can place them on a system file server. 
This will save local resources and make the help information 
available to a larger number of users. The default configura- 
tion is for the run-time files to be installed with the rest of 
the application's files. 

Another important step in installing help files is registration 
(or symbolic links to help volumes). The registration process 



slang 

/user/vhelp/volumes/CT 

HPHelpKilhv Vuetntro hv 
Help4Help.hv Vuelogin hv 
SharedX hv Vuemisc.hv 
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/user/vhelp/families/C/' 

HPVUEhl SharedXhl 



Vuewm hv 
browser hv 
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hpuxetror.hv reboot. hv 
hpuxinlo.hv samprinter.hv 
hpuxreply.hv singleusef.hv 



whiteboard hi 



lb) 



Fig. 5. Help dirt-dory roiitenls. (a) A port ion of a direriory fonlain 
tag help volumes, (h) A directory containing product families. 

enables two important features of the HP Help System: 
cioss-volume hyperlinks and product family browsing. 

Registering a Help Volume. After the run-time files have been 
installed, a help volume is registered by creating an HP-UX* 
symbolic link to the help volume's volume. hv file. The link is 
created in one of the directories that the help system 
searches for help volumes (Fig. 5a). For most help volumes, 
the appropriate place for the link is in the /usr/vhelp/volumes/ 
SLANG/ directory, where SLANG represents the language of the 
help volume being registered. The default language for help 
files is usually English. 

Registering a Product Family. A product family is a group of 
help volumes belonging to a particular product. To register a 
product family, a help family file ( product.hf ) must be created 
with the rest of the product's help files. The family file is 
registered by creating a symbolic link to the product-name.hf 
file. For most products, the appropriate place for the link is 
In the /usr/vhelp/families/SLANG/ directory (see Fig. 5b). 

Family files can be read with the helpgen program (part of 
HP VUE), which creates a special help volume that lists the 
families and the volumes within each family installed on the 
system. 

Access to Help Volumes 

The HP Help System has a simple, yet extensible mechanism 
for transparent access to help volumes installed on the desk- 
top. It supports both local and remote access to help vol- 
umes and works with any number of workstations. The only 
dependencies required are I he proper help registration as 
disc ussed above, NFS services (i.e.. remote systems mounted 
to the local server), and proper configuration of the help 
environment variables discussed below. 

When an application creates an instance of a help widget the 
XmNhelpVolume resource can be set using either a complete 
path to the volume.hv file, or if the volume is registered, using 
the base name (i.e., the file name without the .hv attached) of 
the volume. When using the base name, the help system 
searches several directories for the v olume. The search ends 
when the first matching volume.hv file is found. The value of 
the user's SLANG environment variable is also used to locate 
help in the proper language (if it's available). 
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The environment variable XVHHELPUSERSEARCHPATH specifies 
the user search path for locating help volumes. Whenever 
this resource is set to a relative path, the user's default home 
directory will be prepended to the value contained in the 
XmNhelpVolume resource. The default value used when the 
environment variable is not set is: 

vhelp/%T/%L/%H.hv.\ 

vhelp/%T/%H.hvA 

vhelp/%T/%U%H:\ 

vhelp/%H:\ 

vhelp/%T/C/%H.hv.\ 

vhelp/%T/C/%H. 

where: 

%L is the value of the SLANG environment variable 
(C is the default) 

%T is the type of file (volume or family) being searched for 
%H is the help volume specified. 

These path names are illustrated in Fig. 5. 

The environment variable XVHHELPSYSTEMSEARCHPATH specifies 
the system search path for locating help volumes. The default 
value used when this environment variable is not set pre- 
pends the string /usr to the strings given above. For example, 
vhelp/%T/%LAH.hv:\ becomes /usr/vhelp/%T/%L/%H.hv:\. Note that 
the user search path defined above takes precedence over 
the system search path. 

Run-Time Help Volumes 

The flexibility and power of t his help system is largely 
placed in the author's hands. With the HP HelpTag markup 
language and a creative author, very different and interest- 
ing approaches can be taken with respect to presenting in- 
formation to the end user. Documents can be organized in 
either a hierarchy with hyperlinks referencing the children 
at any given level, or in the form of a network or web, wit h a 
linear collection of topics connected wilh hyperlinks to re- 
lated topics (see "Information Models for Online Help" on 
page 92 for more about these document organizations). It's 
up lo the author to explore the many capabilities with re- 
spect to producing effective online help information for a 
particular system. 

Help Volume Structure. A help volume is a collection of re- 
lated topics that form an online book. Normally, the topics 
within a volume are arranged in a hierarchy. Developers 
usually create one help volume per application. However, 
for complex applications or a collection of related applica- 
tions several help volumes might be developed. Topics 
within a help volume can be referenced by unique location 
identifiers that are assigned by the author. It Ls through 
these location identifiers that help information is referenced 
in the run-time environment. 

Help Volume Authoring. ( Inline help is written in ordinary text 
files. Special codes, or tags, are used to mark up elements 
within i he information. The tags form a markup language 
Galled III' HelpTag. The III' HelpTag markup language defines 
a hierarchy of elements thai define high-level constructs 
such as chapters, sections, and subsections, and low-level 
elements such as paragraphs, lists, and emphasized words 
( Fig. (i). The text files created by authors and any associated 
graphics files :,rv compiled using the HP HelpTag software 



< emit! versionGraphic Rli "b«tn'> 
<metainfo> 

<lflle>Helpdeino 'Sample Application! 
<con"9trt> 

<grapoie enlity=»ersionGraphic><term noglosslHelpdemol. Version 1 0 
<hnan«> 

Scoot: Copyright Hewlett-Packard Company 1932 
All Rights Reserved 
• vmagr > 

"Teas, program n lor demonstration purposes only 1 11 

<atmract>This online help volume is used with the helpdemo program 
thai demonstrates how to use the HP Help System in an OSF/Motif 
application 

<Yneuiirio> 

<homefopic>Helpdemo Help Information 
odafintroductionl 

This is the home lopic This is the top level dI your helpdemo 
help information 

Choose one ol the following links to lind out more about the helpdemo 
program 

<list bulled 

•otrefchapllO> 

' <xrel chap2ID> 
<Misl> 

<chapter id=chap1ID>An Application Help System 

<M bullets 
" <xref onApplicationMenu* 
* <xref sampleBtnOne> 
' <xref sampleBtnTwo 

<Mist> 



<s1 id=sampleBtn0ne>8utton One Help 
Here's the help text for our sample button one. 
<s1 id=sampleBtnTwo>Button Two Help 
Here's the help lert tor our sample button two 
<s1 id=onApplicalionMenu>lntroducing Helpdemo 

This is the topic displayed by choosing On Application from the Help menu 

(chapter id=chap2I0> Controlling The Application 

The lollowing links demonstrate how the HP Help System con control the 
hosting application. 

<list bullet> 

• <link hyperlink* "100" type=AppDelined> Move the window UP <Mink> 

* <link hyperlink='101" !ypecAppDefined> Move the window DOWN <\Jink> 
" <link hyperlink="102" type=AppUefined> Move the window LEFT <Mtnh> 

" <link hyperlink="f03~ rype=AppDefined> Move fhe window RIGHT <Mink> 
<Mill> 

Nole: The text contained in Ihe brackets "< >" is fhe lags lhal lorm the 
HP HelpTag markup language. 

Fig. 6. A sample HP HelpTag volume that is distributed as part of 
Che HP Help Developer's Kit. 

to create run-time help files (Fig. 7). These run-lime files (or 
volumes) are installed with the application and accessed 
when the user requests help. 

Help Volume Compilation. The IIP HelpTag compilation pro- 
cess performs the following tasks in generating a compiled 
run-lime help volume: 

• Syntax validation 

• Conversion from the authored forma) to run-time format 

• Location identifier map generation 

• Topic compression 

• Topic hierarchy map generation. 
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Fig. 7. He HP Hell 'Tug compilation process. 

While creating the help volume compilation process we de- 
veloped techniques for improving the performance (speed 
and size ) of our system. Our objectives were to create a run- 
lime lile format that supported very quick access (three sec- 
onds from request to display) for any requested help topic 
contained within a help volume, while at the same time 
keeping the overall size of the volume as small as possible. 
Topics wil h graphics can sometimes be slower than three 
seconds. 

To solve the quick access problem, a scheme was devised 
I hat takes I he physical hierarchy of authored topics within 
the volume and flattens the whole volume. During this pro- 
cess a. jump table is generated that lists each topic name, the 
file that topic resides in, and the offset into the file that rep- 
resents the beginning of the topic. With this flattened format 
and the jump table, topics can be quickly retrieved for dis- 
play. The jump table is stored in the volume.hv file in X re- 
source format, and parsed using Standard xrm function calls 
in Xlib. 

Help Volume Compression and Decompression. The size of 
compiled run-time help files was a real problem in the first 
prototypes. The solution we developed to solve this problem 
involves compressing the lopics in the help topic (*.ht) files. 
This task was added as the last step in the compilation 
phase of an authored help volume. 

The help data files are compressed on a per-topic basis. That 
is, each help file is read to determine the start and end points 
of each topic in the data lile. This information is used to step 
through the data file, extracting each topic in turn, writing it 
out to a temporary file, and using the HP-UX utility compress(l) 
to compress the file. Unless a special option (-f) is given to 
compress, the utility will not compress a file if the file does 
not actually shrink. (The IIP Help System is able to read 
uncompressed files.) After executing the compress utility, 
the resulting file is checked for a .Z extension to determine 
if compression has actually taken place. 

If the topic is compressed, a null byte followed by three bytes 
making up a 24-bit number holding the size of the topic in 
bytes is written to a new version of the help data file followed 
by the compressed topic. If the topic is not compressed, it is 
simply copied to the new help data file, hi either case, a new 
version of the index file (volume.hv file) is updated with the 
new starting offset of the topic based upon the size of the 
previous topics. 



Since no uncompressed topic will ever start with a null byte, 
the leading null byte in compressed topics serves as a 
""magic number" to indicate to the run-lime help viewer that 
the topic is compressed. The 24-bit size value wrilten to the 
file in a fixed byte order allows help files to work on ma- 
chines with varying byte orders in machine words and is 
used by the decompression algorithm in the run-time help 
viewer to determine when to stop expanding a topic. 

After the entire help dala file has been compressed, the new 
versions of the help data file and index file are moved to 
replace the old versions. 

When the compression algorithm was first prototyped, we 
were pleasantly surprised by the results. The new scheme 
saved over 40% in disk use per volume while creating no 
end-user-visible performance degradation in rendering time. 
We use the standard HP-UX compress! 1 1 command, which is 
called from the HP HelpTag program to handle the compres- 
sion, and an embedded library version of uncompress for de- 
compression at display time. We determined that the lack of 
performance degradation in using compressed topics is 
partly because most of the help topics are very small and the 
embedded decompression function enables fast retrieval. 

Graphics Compression and Decompression. Support is also 
included for compressed graphics including X pixmaps, X 
bitmaps, and X windows, as well as JPEG compressed TIFF 
images, which are supported by the HP Image Library. See 
the article on page 37 for more about the HP Image Library. 
In most cases the best results, both for performance and disk 
use, are gained by using JPEG compressed TIFF images. 

Help Dialogs 

From the developer's perspective the help dialog is seen as a 
single widget. Widgets are created, managed, and destroyed 
as one single object. In reality our help widgets are not one 
monolithic help entity, but two separate very distinct com- 
ponents: t he text display engine component and the widget 
component. The text display engine component as seen 
from the developer's perspective is the region in the help 
widgel that renders the lexl and graphics, provides hyper- 
link access, and performs dynamic formatting of the text. 
The widget component consists of the OSF/Motif Code that 
makes it a widget and the remainder of the user interface 
including topic hierarchy, menu bar, and supporting dialogs 
(print, keyword search, and history). 

The Help Widget. By building the help dialogs as true OSF/ 
Motif widgets (customized or part of a toolkit ) and exposing 
this as our help API, we immediately gained an industry- 
standard format for our help functions. The syntax and use 
model for programmers is the same for every OSF/Motif 
widget created. This makes it very easy for dev elopers famil- 
iar with OSF/Motif programming to understand and use the 
help widgets. 

The OSF/Motif-based .API supports the various controls we 
need to manage an instance of our help dialog. Through 
standard OSF/Motif and X toolkit and Xlib functions, pro- 
grammers have direct access to the help dialog resources 
and can manipulate these values as they see fit. Developers 
can add callbacks via XtAddCallbacM), set and modify re- 
sources via XtSetvaluesO. manage and unmanage the dialogs 
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via XtManageChild and XtUnmanageChild. and free the resources 
when done via XtDestroyWidgetl). 

The Display Area. Text formatting on the display allows dif- 
ferent types of text. The author can specify dynamic text 
that will format or reformat text according to the window- 
size. The author can also specify static text that will not be 
reformatted to adjust to different window sizes. For dy- 
namic text a sequence of two or more spaces will be com- 
pressed into a single space and internal newlines I Returns or 
Enters ) will be changed into a space. For static text all spaces 
and internal newlines will be honored. 

Help system users demanded the ability to resize help win- 
dows. While vertical scrolling is accepted as necessary 
when help topics are longer than the available screen space, 
horizontal scrolling is not. Therefore, dynamic reformatting 
is a must. 

Foreign Language Format. Text formatting for foreign lan- 
guages placed some special demands on our display area 
text formatting widget. 

European (8-bit) rules. For most European languages (includ- 
ing English), breaking a line of text at spaces is sufficient. 
The only other line-breaking rule applied is with hyphens. If 
a word begins or ends with a hyphen, the hyphen is consid- 
ered a part of the word. If the hyphen has a nonspace before 
and after it. it is considered a line breakable character and 
anything after it is considered safe to place on the next line. 
Asian ( 10-bit) rules. For Asian language support, breaking a 
line of text on a space is unacceptable since some 16-bit lan- 
guages do not break their words with spaces (i.e.. Japanese 
and Chinese, but not Korean). With the Japanese language, 
the characters are placed one after another without any word 
breaking character because each character is considered a 
word. There is also the concept that certain characters can- 
not be I he first character on a line or the last character on a 
line. English (8-bit) characters can be mixed with IB-bit 
characters. 

Given these considerations, the following line-breaking rules 
for 16-bit languages are used: 

1. Break on an 8-bit space. 

2. Break on a hyphen if the character before and after the 
hyphen is not a space. 

3. Break on an 8-bit character if it is followed by a 16-hit 
character. 

4. Break on a 16-bit character if il is followed by an 8-bii 
character. 

5. Break between two 16-bit characters if the firsl character 
can be the last character on a line and the Other character 
can be the firsl character on a line. 

Rather than hard code I he values of those Japanese charac- 
ters thai can't start or end a line into our help system, a 
message catalog system is used. This provides a general 
mechanism for any 16-bit language. All language localization 
support people are required to determine which characters 
in their language cannot stall or end a line and localize the 
appropriate native language support (NLS) file. The file /usr/ 
lib/nls/%T/%L/fmt_tbl.cat contains the values of those characters 
that arc used for rule 5 Of the line-breaking rules, [f this file 
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Fig. 8. Text flowing around a graphic 

does not exist for a given language, rule 5 is ignored and line 
breaking will occur between any two 16-bit characters. 

Even using these line-breaking rules, sometimes the lines 
are still too long to fit in the available space. For this case or 
when static text pushes the boundary of the display area, 
I he help system gives up and displays a scroll bar so that the 
user can see the information without having to resize the 
window. 

The help system uses the same routines for processing 
English or multibyte documents. These routines determine 
what line-breaking rules to use based on the SLANG environ- 
ment variable and the character set used in the document. 

If a document specifies an ISO-LATIN 1 character set, the 
display engine does not bother looking at rules 3 to 5 or using 
multibyte system routines. Only when the document and the 
SLANG environment variable specify a 16-bit character set are 
these rules and routines used. This minimally impacts the 
access and rendering time but allows the same binary to be 
used in the United States, Europe, and Asia. 

Flowing Text. The help system display area also provides the 
ability to flow texl around a graphic. This is seen as a space 
saving measure and a highly desired fealure. The graphic can 
be placed on the left side or the right side of the display area 
and the text occupies the space lo the side of the graphic. If 
Ihe texl is loo long and does not fit completely in the space 
beside Ihe graphic, Ihe text wraps below Ihe graphic. Fig. 8 
shows an example of this graphics formatting technique. 

Graphic Manipulation. Complaints about the text -only nature 
of HP Vuehelp 2.0 strongly demonstrate the truth of the 
adage "one picture is worth a thousand words." Therefore, 
ihe help system tries to allow as many standard graphic for- 
mats as possible. During the design of the help system Ihe 
question was, which ones to allow? Eventually, it was deter- 
mined to allow standard X graphics (plus the new X pixmap) 
and TIFF image formats. The reason for selecting the X 
graphic formats is thai they are supported by standard Xlib 
routines for accessing graphics files, and the reason for 
choosing TIFF format is that the HP Image Library supports 
TIFF format. The formats supported by the help system 
include; 

• X bitmaps 

• X window files 

• X pixmap files 
. TIFF 5.0. 

Graphic Compression. While JPEG compression schemes are 
common for use with TIFF files, no compression was being 
Used with the X graphical formats. After numerous com- 
plaints from authors about how much space Xwd files 

Iconlinued on pane U8) 
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WYSIWYG Printing in an X Application 



The HP Help System provides several features that allow authors to specify different 
fonts in various sizes and combine them with graphics bitmap illustrations. These 
capabilities and others created special challenges when it came to WYSIWYG 
(what you see is what you gel) printing The HP Help System developed some 
sophisticated techniques for handling WYSIWYG printing 

What Is WYSIWYG? 

Our market research uncovered a strong demand for WYSIWYG printing withoul a 
clear definition of what WYSIWYG really meant. One obvious interpretation is the 
screen dump that accurately represents on paper what is on the screen This is 
appropriate for some applications, but prototypes uf this approach showed jagged 
characters crammed into a small 4-by-6-inch window on a large 8'/j-by-11-mch 
piece of paper. This satisfies no one. Another approach is to take a printed image 
and display il on the screen matching line breaks as they appear on the printer. 
This approach compromises readability on the screen, which is not acceptable for 
an application providing online informalion. Fig. 1 shows one interpretation of 
WYSIWYG printing. 

The interpretation of WYSIWYG we chose for our help system is based on the 
notion that "WYSIWYG is a state of mind." True WYSIWYG is undesirable, but an 
appropriate illusion of WYSIWYG is the right answer For the HP Help System, we 
give presentation on the screen and presentation on the printer separate consider- 
ation The printed page uses the same fonts as the screen (sans serif for the body 
of the text and serif fonts for titles), but printer fonts are laid out and rendered at 
300 dots per inch. The help topics are laid out to fit on the sue of the printed page, 
and each page has page numbers. Thus, line breaks and page breaks on paper do 
not match line breaks and screenfuls on the display, but this is just what our cus- 
tomers are looking for. Fig. 2 shows a comparison of screen and printer output 

Font Availability 

We took care to allow the HP Help System to work with any X server. This was 
important to us. since we knew Dur work was likely to be ported to other platforms 
besides the HP-UX operating system. What is more, the distributed nature of X 
means that even though the application may run on an HP-UX computer, it can be 
displayed on a totally different device, such as an HP Vectra PC running an X 
server under Microsoft''' Windows. It is difficult to predict what fonts might be 
available to the server 

To enable the help system to use fonts available on any display server as well as 
those built into HP LaserJet printers, we developed a table that maps generic help 
fonts to specific fonts available on the target server or printer. After having studied a 
variety of HP documentation, we identified a need for three font families for help 
messages: a serif proportionally spaced family (like Times), a sans serif proportion- 
ally spaced family (like Helvetica), and a serif monospace family (like Courier). 
Each family contains four treatments normal, bold, italic, and bold italic. Table I 
shows these fonts. For special characters, a symbol font is also included Our 
discovery of this was no surprise. It corresponds very closely to the 13 typefaces 
typically found in PostScript'" printers and in the HP LaserJet III printer. 



This is a screen display that uses printer metrics. 
It will look really great printed out, but on the screen, 
the character spacing is very uneven. This is especially 
evident when the same character is repeated as in the 
rows of characters below. Notice also how some letter 
combinations are uncomfortably crowded together-! 
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Typeface 
Category 



Serif 
Sans Serif 

Monospace 



Table I 

HP Help System Generic Fonts 
Treatments 



Normal 


Bold 


Italic 


Bold Italic 


A 


A 


A 


A 


A 


A 


A 


A 




A 


A 


A 



For screen use. we mapped our generic fonts to fonts included in the standard X 
distribution, which is available on most if not all X servers The distribution uses 
New Century Schoolbook, Helvetica, and Courier fonts. Should these fonts not be 
available, an administrator can change the mapping table. The table is in an X 
resource file For situations in which all the fonts are not available, several generic 
fonts can be mapped to the same physical font We did this with Asian languages 
in which all four typeface treatments are not available. For Japanese, the serif 
family is Mincho and the sans serif family is Gothic, but all treatments are mapped 
to the one treatment available 

For HP LaserJet III printers, we used the same scheme to ensure we used the 
built-in fonts CG Times, Univers, and CG Courier. Thus, the fonts on the printer are 
not identical to those on the screen, but they are close enough to create a 
WYSIWYG state of mind to our users Table II shows various font family mappings 

As an example of how this mapping works consider an application that requests a 
sans serif bold 12-point font This request will be honored with Helvetica on a 
European X server, Univers on an HP LaserJet III printer, and Gothic on a Japanese 
X server. 



Table II 

Font Family Mappings to Printer or Screen 
Fonts Available 

HP LaserJet III 



Typeface 
Category 

Seril 



Sans Serif 
Monospace 



X Server 
(European) 

New Century 
Schoolbook 

Helvetica 

Courier 



CG Times 

Univers 

Courier 



X Server 
(Japanese) 

Mincho 

Gothic 
Mincho 



illinium 

Fkj. I. One interpretation ot WYSIWYG printing. 



Use ol generic fonts worked so well for us that we are now investigating ways to 
build this capability into X font servers so that applications can be assured of a 
reasonably rich set of fonts no matter what the platform or the current locale. 

Xlibfor Printing 

The traditional approach to the implementation of printing in an application is to 
write the rendering code at a reasonably high level and then write specific drivers 
that convert from the higher-level code to the page-description language of the 
printer With this approach an application might end up with a large number of 
drivers, one for each specific type of printer 

We addressed printing rather late in the development cycle By the time we began 
developing printing support, the rendering code had already been written directly 
to Xlib, making it difficult to develop a higher-level tool kit as described above. We 
turned this vice into a virtue by experimenting with a new concept using Xlib 
functions. 

Using some X toolkit and X motif routines we developed a clone of Xlib called 
Xvplib, which has the same functions as Xlib, but generates PCL instead of X 
protocol. Printing is done through a separate program called halpprini which is 
called by the help widget The helpprim program uses the same help library (Xvh) 
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Fig. 2. A comparison between display lien) and printer (right) output from the help system 



as the display program, bu! links with Xvpub instead of Xlib (or the printer driver 
code (see Fig 31 

The helpprim application uses the Xlib call xrjpenDispfayO to open a printer and 
then uses the XCreateSimpleWindowO routine to create a window on the print 
display This window reflects the margins on the page. The help-rendering library 
(Xvhl then renders the current help topic into the window. The rendering process 
performed by Xvh involves retrieving the window size using XGetWindowAnributest). 
loading fonts using XloadQueryFont, and using XDrawlmageStringO to render text 
until done The XvpUb library provides the Xlib functions and generates the PCL code 
required Many pixel arguments such as width, height, x. and y are much larger to 
printer displays than to screen displays because of the 300-dpi resolution of the 
printer. Howevei, calls such as XTextWidthO. which leturns the space required to 
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draw a siring, slill work line. The XvpLib library supports bolh the HP LaserJet II 
(PCL 4) and the HP LaserJet II! (PCL 51 printers The primary difference between 
them is the selection of built-in fools The match from X to PCL was surprisingly 
close, but some X calls (such as xORing bitmapsl had to be interpreted liberally. 
XvpLib supports all 36 X functions used by the help topic library Xvh 

Using X as our punt interface worked very well Only about three lines of code had 
to be added to the help-rendering library (Xvh) to support printing Common render- 
ing code for the screen and printer made it easy for us to keep the layout of help 
topics consistent between screen and printer 

Printing for Special Printers 

The printing approach described above works very well with PCL printers However, 
HP customers in Japan presented us with special challenges Fust, the Japanese 
language requires support for 16-bit text, and these customers typically have 
printers that support Asian page description languages such as Canon's LIPS and 
Ricoh's FtPL 

To support such requirements, we took a different approach Instead of using 
helpprim to rendei to the printer, we developed another rendering program called 
heipprintrsi This program creates an offscreen pixmap the size of a sheet of paper 
on the X server and and then calls Xvh to render into that pixmap The print pro- 
gram retrieves the completed page using XGetlmagel) and sends it to the printing 
library (XvpLib) to turn the image into a PCL bitmap Special filters in the print 
spooler convert the PCL bitmap into a bitmap suitable for the target printer 

Axel Deininger 
Engineer/Scientist 
Workstation Technology Division 

Microsoft is a U S registered trademark ol Microsoft Corporation. 

PostScript is a trademaik ol Adobe Systems Incoipoiated which may be registered in certain 
jurisdictions 
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require, the help system was modified to find and access 
compressed files. The author uses the same HP-UX com- 
pression utility mentioned earlier to compress the graphic- 
files. The same internal decompression routine used to de- 
compress topic files is used to decompress the graphic files 
into a temporary file. After decompression, the help system 
reads the graphic file as usual. 

Using compression on X graphic files can impact access 
time. For very large graphic images or for a topic that uses 
many graphics, this impact can be noticeable. The trade-off 
between speed and disk space is one that the author and 
application engineer must address. 

Color Degradation. Another obstacle encountered with han- 
dling graphics was color graphics on grayscale or black and 
white displays. Having to provide three different images for 
the three types of displays is not feasible because of disk 
use. Therefore, the help system has to degrade a color image 
for grayscale or black and white displays. 

For X bitmaps, this is no problem since bitmaps are specified 
as using the foreground and background colors only. For 
TIFF images, the HP Image library forces the image to the 
proper color set depending on the display type. For X pix- 
maps. the Xlib routines take the same approach depending 
on the display. This leaves the X window files to manipulate. 

The task is to reduce an Xwd file from a full color image to a 
grayscale image containing no more than the maximum 
number of gray colors we have available. This number is kept 
in a variable called MAX_GRAY_C0L0RS. The I IP Help System 
uses eight gray colors. The first step in this process is to map 
each of t he X window color pixels to a grayscale luminosity 
value (fS in Fig. 9). This is done using the NTSC (National 
Television Standards Committee) formula for convening 
RGB values into a corresponding grayscale value: 

luminosity = 0.299 x red + 0.587 x green + 0.114 x blue 

where red. green, blue are the X window color values in the 
range of 0 to 255. This creates a grayscale luminosity value 
in the range from 0 to 255. 

The next step is to determine the number of distinct lumi- 
nosity values used in the image. This involves counting the 
total number of luminosity values computed above ( 1 in 
Fig. 9). The idea is to group the grayscale luminosity values 
across the available gray colors so that the image can be 
evenly and reasonably rendered. 



Alter determining the actual number of distinct luminosity 
values used in the image, a further calculation is done to 
determine which gray color to use for a given group of lumi- 
nosity values (<i> in Fig. 9), If the number of distinct lumi- 
nosity values is greater than or equal lo MAX_GRAY_C0L0RS. 
then each gray color will be used at least once. However, if 
the number of dist inct luminosity values is less than 
MAX_GRAY_C0L0RS a calculation is performed to spread the 
color load among the gray colors instead of bunching them 
together. This provides the contrast in an image. 

Finally, when the image is rendered to the display the shade 
of gray associated with a particular group of luminosity val- 
ues is mapped to the appropriate display pixel ( t in Fig. 9). 

If the system lias to degrade the image to black and white, it 
first calculates the grayscale colors using the luminosity cal- 
culation described above. Then it dithers the image using a 
Floyd-Steinberg error-diffusion algorithm, which incorporates 
a Stucki error filter/ 1 

The end user can force the whole environment including the 
help system to use grayscale or black and white by setting it 
via the HP VUE style manager's Color Use dialog. Also, if an 
image uses more colors than are available in the color map. 
the help system will automatically degrade the image until it 
is renderable. 

Hard-Copy Support 

A critical and difficult requirement of this help system was 
to provide WYSIWYG (what you see is what you get) print- 
ing support to match our text display capabilities. To ensure 
good performance and not tie up an application just to print 
out its online help, we implemented the printing mechanism 
as a separate application. When an end user requests to print 
one or more topics in the current help volume, the widget 
code packages the request and performs a vfork(2) to launch 
the print application. 

The help system supports two different print applications: 
helpprint which is for HP LaserJet printers (i.e., PCL support ) 
and helppnntrst for printing help volumes that contain multi- 
byte characters such as those used in some Asian languages. 
The helpprintrst command operates .just like the helpprint com- 
mand except that its output does not depend on printer 
fonts. Instead, helpprintrst creates a page-size graphic image 
of each help topic. 
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a full COlOt image lo a grayscale 
image. 
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This section covers various e>aBC>les or Ic-cahred 
text. The intent it to test ho» our line-breat rules 
•ork with ttie 16-bit text. Each evaacle is just a 
body of te*t designed to test each of the various 
line break rules m the localired language. 



Fig. 10. A loculizfd lu-lp window. 

Tlie goal in implementing a WYSIWYG printing solution for 
the help widgets was centered on creating a solution that 
could solve the printing problem for many applications, nol 
just the HP Help System. Refer to 'WYSIWYG Printing in an 
X Application." on page 86 for a description of the priming 
solution used by the HP Help System. 

Locaiizabittty 

The HP Help System supports the authoring and displaying 
of online help in virtually any language. The online help in- 
formation can be authored and translated in either single- 
byte or multibyte character sets. All the components within 
tbe developer's kit are multibyte-smart and can parse and 
display the localized information. 

The help widgets use the SLANG environment variable to de- 
termine which language directory to search to retrieve the 
requested help volume. For example, if SLANG = Japanese 
when the request to display help occurs, the widget, code 
will attempt to open the Japanese localized version of that 
help volume. If one does not exist, then the default version, 
which Is English, will be used. 

When an authored help volume is compiled via HP HelpTag, 
the author sets the proper character set option. The character 
set information is used at run time to determine the proper 
fonts to use for displaying the localized help text. The default 
character set for the HP HelpTag compiler Ls the one defined 
for 8-bit character sets by ISO 8859-1. Currently only one 
character set per volume is supported. 

Fig. 10 shows a sample of a localized help window. 

Parsing Multibyte Characters, lb make a single tool work for 
single-byte and multibyte character sets without constantly 



checking for the length of the current character, all charac- 
ters are converted to wide characters on input. This input 
conversion is driven by either command line option, on an 
HP HelpTag entity file, or by the current setting of the locale. 
All internal processing of characters is done on wide charac- 
ters with those wide characters being converted back to 
multibyte characters on output. Single-byte character sets 
are treated just like nudlibyte character sets in that the 
same input and output conversions always take place. 

This scheme of doing all internal pnicessing on wide charac- 
ters has proven to be a very effective means for making one 
tool work for all languages. The scheme did require imple- 
mentation of wide character versions of most of the string 
functions (e.g., strcpy, strlen ) but those functions were all 
quite straightforward to create. 

Localizing User Interlace Components. The menus, buttons, 
labels, and error messages that appear in help dialogs also 
support hill localization to native languages. The help dialogs 
read the user interface component strings from a message 
catalog named Xvh.caL Different localized versions are sup- 
ported by default and included with the developer's kit. For 
languages not supplied with the help system, the developer 
must translate the message catalog /usr/vhelp/nls/C/Xvh.msg and 
then use the gencat command to create the needed run-time 
message catalog file. 
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Developing Online Application Help 



The primary goal for an application help system is to provide the capability 
for the end user to get useful help information and get back on task as 
quickly and successfully as possible. 

by Dex Smith 



Nearly 2000 online help topics are shipped with the HP 
MPower product. Throughout the HP Vl'E 3.0 and HP MPower 
projects, we've learned a lot about online help and its role 
with application software. 

This paper describes online help and covers many of the 
issues encountered by application developers and authors. 
First, we outline the purpose of online help and suggest a 
use model. Second, two common information models are 
described, including how each relates to the domain of online 
help. Next, we discuss what is perhaps the most challenging 
and controversial topic in online information — navigation. 
Although this paper won't go into the details of these debates, 
it does reference some of the concents and issues. Finally, 
we examine the roles of developers in a typical project , and 
we look a( how these roles and online help systems may 
change in the future. 

Although much of this material was developed during the 
design of the HP Help System and includes examples from 
that product, most concepts and ideas can be applied to any 
help system. The details of the implementation of the HP 
Help System are described in t he article on page 79. 

The Role of Application Help 

To understand the purpose of online help, we begin with a 
prioritized list of goals, called a goal hierarchy. 1 Our goal 
hierarchy for online application help consists of the 
following: 

1 . The user leaves the help system. 

2. The user is satisfied with the help information. 

3. The application's response to the user's request for help is 
appropriate. 

-1. The help information is appropriate, even if the system 
response is not. 

5. The user can pursue additional information. 

From the user's perspective, the first two goals are clearly 
most important. The user wants to get out of the help system 
and back to work. Obviously, we want the user to return to 
work with useful information. 

To application developers, goal 3 is an important reminder 
that help is part of the application. A well-designed applica- 
tion will use everything at its disposal (current modes, recent 
user actions and errors, and other contexts) to determine 
the best possible response to a user's request for help. 



Goal 3 is also important to designers of a help system. It 
emphasizes that the design must provide the flexibility and 
power for application developers to integrate online help 
that is capable of responding as the user expects. 

The fourth goal represents the help author's obligation to 
design and deliver the most appropriate information. It fur- 
ther acknowledges that there may be limitations in the help 
system, or in the application's use of system features, that 
the author may need to work around in designing the online 
information. 

Finally, with the fifth goal, if the user's need is not immedi- 
ately met, the system must allow the user to seek additional 
information. 

All of these goals can be summarized in a single prime direc- 
tive for an application help system — get the user back on task 
as quickly and successfully as possible. 

The Application Help Use Model 

Since the overriding principle for providing online help is to 
get the user back on task, online help must be easily accessi- 
ble within whatever applications the user has chosen to ac- 
complish the task. To that end, online help is cast in a sup- 
porting role. That is, the help system's job is to function as 
part of the application with the purpose of making the user 
successful with the rest of the application. 

Keeping the help system tightly coupled with the application 
improves the user's perceived ptvximity (i.e., keeping the 
user feeling close to the application). If deviations to get 
help don't take users far from their current context within 
the application, they are more likely to stay on task and be 
productive. Avoiding unnecessary context switches is a 
fundamental human factors guideline. 

The software architecture used to implement the help sys- 
tem doesn't necessarily have to be part of t he application. 
The HP Help System's toolkit allows software developers to 
embed the help system within the application or to create a 
standalone help server. 

If the help server model is used, special attention must be 
given to window manipulation and user interface design, so 
that the user still perceives the help as part of the application. 

Handling Help Requests 

In its simplest form, the interaction of a help system is a 
request/response transaction model. A request is made that 
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represents a need for information, and the system responds 
by providing information that meets the need. 

For HP Help, we have categorized help information retrievals 
using the terms automatic, semiautomatic, and manual as 
follows: 

Automatic help. The application determines what help to 
present and when to present it. For example, an error mes- 
sage is automatic help because the application automatically 
provides information to the user. (This is sometimes called 
system-initiated help.) 

Semiautomatic help. The application determines what help 
to present based on the current context in the application. 
The user determines when information is presented by mak- 
ing a request for help. The de facto standard gesture for iliis 
kind of request is pressing tiie F1 key. 
Manual help. The user requests a particular type of help. In 
this case, the user determines what kind of help and when to 
deliver it. Most manual help requests are made by choosing 
a help command from the applications Help menu. 





Help 








Print Report 

Prints trie current report to trie default printer. The 
format of the report is set using options in trie Options 
menu and In trie Print dialog box 

To cancel a print job, crioose Cancel in trie Print 
aialog box 

See Also 

• ChoosinQ a Printer 














OK Backtrack j Browse ... | Print 


1 





Fig. 1. A sample quick help dialog from the HP Help System 



Entry Points into Help 

When a help request is made (either by the user or automati- 
cally by the application ). the system responds by displaying 
a help topic. Each topic that can be displayed directly as the 
result of a help request is called an entry point. That is, if 
there is at least one way to get directly from the application 
to a help topic, then that help topic is an entry point into help. 

Any single topic may be an entry point from more than one 
context within the application. The redundancy of overload- 
ing entry points in this way can often be advantageous to 
I he user.- For example, a topic on entering numeric data 
may be appropriate help for many places within a database 
application. 

Styles of Entry Points. ( hir goal hierarchy and use model has 
led US to classify two styles of entry points for help topics: 
Quick help. This style presents a focused topic for 1 1 * * - cur- 
rent context, intended to meet the user's need and then to 
be immediately dismissed. 

Genera] help. This style presents a help topic for the given 
request with the understanding that the user is likely to 
want additional information. 

Comparing the two styles is like contrasting an information 
OQOth with a consulting office. At an information booth, 
contexts are well-defined, questions are generally short, and 
answers come quickly enough thai there's no need lo sit 
down. In seeking the services of a consultant, however, the 
expectations are different. You want to make good use of 
your time to learn, see examples, anil explore related 
subjects so you don't have to come back. 

An entry point into help is the first thing a user sees when a 
help request is made. The presentation, user interface, and 
information content set the user's expectations about how 
specific the information Ls to the current context and how 
quickly it can be dismissed. 

For most applications of even moderate complexity, a com- 
bination of both styles of entry points is appropriate. The 
next two sections describe each style in more detail. 

Topics that are nol entry points can be reached only by 
navigating from oilier topics or by other means within the 



help system. Therefore, the organization and relationships 
between help topics are important to designing appropriate 
entry points. The impact of the organization of help topics 
on navigation is discussed later. 

Quick Help. Quick help entry points are optimized by writing 
style, presentation, and user interface to get the user back 
on task with minimal interruption. Quick help should have a 
very simple user interface and present easily consumable 
portions of information. 

The quick help concept addresses the first goal in our goal 
hierarchy: User leaves the system. The second goal — User is 
satisfied with the help information — is up to the designers. 
That is, the correct entry point must be displayed and it 
must contain correct and useful information. 

Quick help topics typically have a high level of context sen- 
sitivity and contain very specific information. By design, the 
CORtenl and presentation of quick help should not encour- 
age the user to explore. Hypertext links (hyperlinks) should 
be used sparingly, and restricted to closely related topics. 

Notice the Browse. . button in Fig. 1. This is an example of 
how goal 5 in our goal hierarchy can be addressed for quick 
help. That is, the Browse, button provides a path for the 
user to seek additional information. 

Quick help entry points are recommended for automatic and 
semiautomatic help requests. Some manual help requests 
may also use quick help, depending on what type of informa- 
tion is being requested. For instance, users expect minimal 
interruption when requesting "help on version" to gel copy- 
right and version information. 

Typical uses of quick help include t he following: 

• Error messages, progress information, and feedback on 
user actions 

• Context-sensitive help I invoked with the F1 key or Help button 
in a dialog) 

• Spot help (help on a particular item or area on the display) 

• Application copyright and version 

• Simple help on help. 
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General Help. General help typically covers the remaining 
entry points into online help. General help may have a more 
feature-rich interface for searching and browsing. Typical 
uses of general help include: 
Application overview 

A follow-up to quick help when quick help isn't enough 
(This use may follow one or more steps in a progressive 
disclosure sequence (described below).) 
Tutorials (Some tutorials may want to be more restrictive 
on navigation and prefer to use the quick help model.) 
Online documentation. (For browsing online information 
written and organized like a traditional manual.) 

A sample general help dialog is shown in Fig. 2. 
Progressive Disclosure 

Even the besl online help implementations are unlikely to 
provide entry' points into help lopics that meet every user's 
need for each possible situation. 

So, what if a quick help entry point doesn't fill the user's 
need? Progressive disclosure sequences are designed to 
maintain a sense of proximity, while exploring a constrained 
path of topics that incrementally provide more information 
for tiie given context. (This concept is sometimes called 
progressive revelation or progressively more help.) 

Often, a progressive disclosure sequence leads the user 
from initial "how to" context sensitive help through topics 
that are more motivational ("why") and eventually to de- 
tailed reference information. Generally, these sequences use 
a simple quick help interface for the first two or three pro- 
gressions. At the point in the progression when the subject 
matter will likely lead the user to want to browse, the inter- 
face should provide additional browsing capability. 

Fig. 3 shows how a quick-help dialog can provide a More 
button for walking through a progressive disclosure se- 
quence. In each step in the sequence the dialog is reused, 
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Toolboxes for Managing Applications 

Toolboxes are containers for applications, actions, and 
other accessories. Here's a desenpoon of the toolboxes 
available from the HP VUE Front Panel: 



v our Personal Toolbox is (or applications and 
accessories you usere pularry. 




- Shows Depth 
and tocation 
Within the Help 
Volume 



The General Toolbox provides access to 
applications and accessories installed on your 
system 

Tne Network Toolbox provides access to 
applications and accessories stored on other 
systems on the network. 

Marketplace is a place to look for information 
about application software or other products 
available for your wort station. 



Hyperlinks for 
Navigation to 
Other Topics 



NOTE 

Toolboxes are not available in HP VUE Lite. Instead, 
the Tools subpanei contain a few common applications 



until the last step when the More button is renamed Browse 
and leads to a general help dialog. 

Information Models for Online Help 

In designing online help for an application, it is important to 
organize the information in a way that best fits the applica- 
tion. A tight coupling between the application and its help 
information typically makes the information more useful 
when ii is needed. 

The help topics associated with an application are collec- 
tively called a help volume. Essentially, a help volume is like 
a book or document for the application. (However, we avoid 
the terms "book" and "document" because they tend to skew 
expectations. Further, some help volumes may have very 
little in common with their paper counterparts, such as a 
table of contents, chapters, and so on.) 

Typically, there's a single help volume for each application. 
For very complex applications, or applications with distinct 
user groups, multiple volumes may be appropriate (Fig. 4). 

Standalone Help Volumes. Not all online help is directly associ- 
ated witli an application. Help for the operating system, for 
example, isn't associated with any single command, program, 
or utility. Therefore, the information models for online help 
must allow for standalone help volumes. 

Since standalone help volumes are not associated with jui 
application, there must be a way to access them. One 
method is to provide a help manager. A help manager is 
simply an application that treats one or more volumes as its 
own and provides navigation into each volume. A help man- 
ager may provide entry points into help volumes that are 
also accessible from applications as shown in Fig. 5. 

Implicit Relationships. Within a help volume, there are two 
significant organizational models: hierarchical and nonhier- 
archicaL Most technical information is organized hierarchi- 
cally like a traditional manual, in which chapters contain 
sections, sections contain subsections, and so on. Relation- 
ships between nodes of informat ion are created implicitly 
based on the hierarchy created by the author. Fig. (5a shows 
a typical topic hierarchy. 

Hierarchical navigation fends to give users more confidence 
in knowing where they are. There is a sense of depth (num- 
ber of levels from the top) and movement (up. down, lateral). 
Hypertext links can be added to connect nonatfjacent. but 
related topics (Fig. fib). In this case, hypertext is perceived 
as a bonus, because it provides jumps that span the hierar- 
chical structure. 

Explicit Relationships. The free-form nature of a nonhierarch- 
ical information web allows authors to organize their infor- 
mation into hierarchies, circles, trails, webs, and grids. Fig. 
fie shows an information web. Relationships are created 
explicitly with hyperlinks. (In some systems, end users can 
create their own links to connect related lopics.) 

When navigation is based entirely on hypertext, authors 
have much more flexibility to create any type of structure. 
This lev el of freedom requires a higher level of skill on the 
author's part. Links to and from each node must be designed 
and tested carefully, 



Fig. 2. A sample general help dialog from the HP Help .System. 
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The first topic in (he sequence 
provides specrfic information 
about the user s context — in this 
case, a description of a control in 
theHPVUE from panel. 
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Since customization is an impor- 
tant part of a personal toolbox, the 
second topic in the sequence pro- 
vides basic ""how to" information. 



as 



- The third topic exposes some 
important related topics and 
terminology 



- The Browse button opens a 
general help dialog. 
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Fig. i. The association of help volumes In applications. Most he! 
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Hypertext Links. Tin- lightning speed of hypertext links, and 
their ability to jump a user to a c ompletely different area of 
the online information, leaves most users feeling lost after 
only a few jumps. 

System designers and authors must recognize that each hy- 
pertext link is an invitation to explore, and therefore, also an 
invitation to get lost. Most research in this area indicates that 
hypertext is best used in combination with other navigation 
aids — "Hypertext is a spice, not a main course." 3 

Usability testing on the 111' Help System indicates that when 
hyperlinks are used to navigate down the topic hierarchy, 
other links that span the hierarchy should be distinguished 
in some way. In HP MI'ower help, most help volumes use a 
convention of labeling lists of "Subtopics" and "See Also"s to 
make that distinction. 

Die I IP Help System provides the following features to help 
users avoid getting lost in hyperspace: 
Backtrack command for undoing a hyperlink and going 
back to the previous topic 

Topic hierarchy display (in the general help dialog) to show 
"you are here" information within the current help volume 
History dialog that lists the titles of the topics recently visited 



Fig. 3. A progressive disclosure 
sequence 



• A "home topic" at the top of each hierarchy to give users a 
known place to return to if they get lost. 

The Developers' Tasks 

TheM are many facets to developing an application with on- 
line help. Depending on organizational structure and the size 
of the project, these tasks may be performed by a variety of 
team members. 

Planning and Design. Planning and designing a Help system 
for ;ui application requires close collaboration between de- 
signers, authors, and programmers. First, I he design team 
must understand the user's need for the application and the 
tasks that users will perform. Front this information a use 
model can be developed that describes the users interaction 
wilh the application. 

As a user interface is designed based on the use model, every 
effort should be made to keep things as obvious as possible, 
limiting the need for online help. Morton defines obvious as 
"... designing products that users already know how to 
operate ... or can learn by trying things out." ;J 
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Fig. 5. A help manager provides access to all help volumes. 



volumes are associated with a simple application 
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Fig. 6. Help volume organizational models, (a) A typical topic 
hierarchy. (b) Hypertext links provide shortcuts to span the topic 
hierarchy, (c) An information web. 

For every context within the application that is not com- 
pletely obvious, identify it as an entry point into help. Assign 
a unique identifier for connecting the application context to 
a help topic. Most help systems have an identifier naming 
scheme. In the HP Help System an identifier can be any string 
up to 64 characters including letters, digits, and hyphens. 

Authoring. The author's job includes writing all of (he help 
topics, assigning the corresponding identifiers along the 
way. For each help topic, the author must consider the many 
ways the topic may be read. For example, a topic that is 
typically seen as an entry point (displayed directly when the 
user requests help) may also be part of the browsable topic 
hierarchy. The topic must be authored to work well in both 
contexts. 

The breadth and depth of exposure that an author has to the 
product during the writing process provides an opportunity 
to discover design flaws that may decrease usability. It con- 
tinues to be the author's responsibility to reduce the need 
for online help by exposing these kinds of problems. 

Programming. The software developer is responsible for pro- 
viding the hooks from the software into online help. This 
requires using the agreed upon topic identifiers for displaying 
topics when the user requests help. 
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Fig. 7. Application help architectures, (a) The traditional applica- 
tion help architecture, (b) A possible migrat ion of lite traditional 
application help architecture, (c) Another possible migration of the 
traditional application help architecture. 

Depending on the help system being used, there may be some 
additional programming necessary to achieve the desired 
behavior. For instance, with the HP Help System, progressive 
disclosure sequences like the one shown in Fig. 3 require the 
application to provide the correct behavior for the More 
button that walks through the sequence. 

The Future of Online Help 

Much of Ibis paper has assumed a traditional approach to 
online help development. That is, one in which the help sys- 
tem and its supporting information are aligned with the ap- 
plication's user interface and supporting functions. Context 
sensitivity is enabled by direct connections between the 
help system and user interface components and states 
within the application. Fig. 7a shows a traditional applica- 
tion help architecture. 

Reference 4 describes a help system whose design is driven 
by I he same knowledge base that drives the user interface 
(via a user interface management system, or UIMS). In this 
model, the flow of information and functionality is all handled 
through the UIMS which presents the user interface for the 
application and the help system (see Fig. 7b). 

Online information systems of the future may evolve from 
architectures like the one suggested by Foley and col- 
leagues. 1 However. I expect help systems to meld further 
into the application, to the point that the help system itself 
isn't identified as a discrete component. 

As this takes place, the engineering process for the informa- 
tion and knowledge portions of products will be as important 
as the traditional hardware and software engineering tasks. In 
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fact, the information architecture will become increasingly 
difficult to distinguish from the application architecture. 

An intelligent user interface will draw upon an information 
base and the application functions to present user interface 
components (see Fig 7c). The user interface may still present 
what the user perceives as online help, but it is generated 
from a combination of knowledge and application functions, 
along with the user's current context Further, there will be 
a strong relationship between the knowledge base and the 
application functions (a channel missing in Foley's model). 

Conclusion 

Providing online help has grown in recent years from a "nice 
to have" feature to an expected component of all significant 
application software. For some products, online help re- 
duces support costs because it puts information where the 
user is more likely to find it (meeting the goals in our goal 
hierarchy). For other products, providing online help also 
reduces the cost of printing hardcopy manuals. 

As applications continue to grow in complexity, so does the 
need to simplify them for users. For the foreseeable future, 
online help plays an important role in helping with that sim- 
plification. Today, online help systems are discrete compo- 
nents that aid application developers in packaging easier- 
to-use products. In the future, online help will become a 
by-product of an information engineering process that 
addresses all information aspects of a product 
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